3. Komplex szoftver rendszerek fejlesztési módszertana A módszertan fejlesztési elvek, módszerek, eljárások és eszközök meghatározott halmaza, mely rendszerint a teljes fejlesztési ciklust, vagy annak több fázisát átfogja. A bizonyos fejlesztési feladatok elvégzésére alkalmas komplex módszertant keretrendszernek is szokták nevezni. A legsikeresebb módszerekből tekintünk át néhányat. •
SSADM
•
DARTS
•
DOMINO
•
I-CASE
•
ORACLE CASE
A felsorolás nem teljes, csak példajellegű, hogy a jellegzetes megközelítéseket bemutassuk. Valójában ide sorolható az EUROMETHOD is, de ezt külön tárgyaljuk, mert nem magára a szoftver termékre, hanem egy információtechnológiai beruházás megvalósítására vonatkozik.
3.1. STRUKTURÁLT RENDSZERANALÍZIS ÉS TERVEZÉSI MÓDSZERTANA (Structured System Analizys & Design Method) Az SSADM fejlesztését Angliában a 70-es évek végén fejlesztették ki (Learmonth and Burchett Management Systems) a kormányzat támogatásával. A módszertant a National Computing Centre szabványosította. Azóta a világon széles körbe terjedt el. Folyamatosan továbbfejlesztik és újabb verziói jelennek meg, az alapelvek azonban változatlanok. Magyarországon a módszer a GKM támogatását élvezi, és elsődlegesen alkalmazott módszer a nagy projektek tervezésénél. Számos támogató szoftver létezik az alkalmazáshoz, de elvileg papíron, ceruzával is megvalósítható. AZ SSADM ALKALMAZÁSÁNAK OKAI a. A rendszer időre történő elkészítése: ⇒ A hierarchikus felépítésű rendszerben több ellenőrzési pontot (legalább nyolcat) határoznak meg, amely pontokban végrehajtott ellenőrzés során a vezetés képet kap a projekt helyzetéről és amennyiben szükséges érvényesíti a szükséges korrekciókat. b. A felhasználó igényeit kielégítő rendszer készül: ⇒ A felhasználó számára grafikus ábrákkal érhetővé, áttekinthetővé válik a fejlesztési tevékenység eredménye. ⇒ A követelmény központúság lehetővé teszi a felhasználó bevonását a projekt tevékenységébe. A projekt irányítás dönt az egyes döntési pontokban, szem előtt tartva a felhasználói követelmények mind teljesebb kielégítését.
c. A fejlesztés eredményeként kialakuló rendszer követni tudja a környezet változásait: ⇒ A rendszer jól dokumentált, az egyes munkafázisban a célokat világosan rögzítik. ⇒ A megvalósítási dokumentációból kiderülnek a fejlesztők szándékai. d. A meglévő szakértelem hatékony használata, átvétele: ⇒ Az SSADM átvette és használja a más programozási rendszerben sikeresen alkalmazott eszközöket (egyed, egyedtulajdonság, objektum, obj. tulajdonság, szülő objektum stb ). Eltérés csupán a "kapcsolat" fogalmának alkalmazásában észlelhető. e. A minőség javítása a hibák csökkentésével: ⇒ Többszempontú megközelítés. ⇒ Pontosan előírtak a tesztelési követelmények. ⇒ A dokumentumokra vonatkozó előírások a teljességet biztosítják. f. A hajlékonyságnak a növelése: ⇒ A projekt irányítás határozza meg a feladatokat és ez lehetővé teszi, hogy a kritikus részeket biztosítják. g. A termelékenység növelése: ⇒ A folyamat jól dokumentált. A dokumentáció jól tanítható és jól megérthető. ⇒ A termékközpontúságból eredően, megvéd a fölösleges fejlesztési lépésektől, és a feleslegesen felduzzasztott dokumentációtól. (Pl.: a vízesés módszertől jelentősen kisebb mérettű a dokumentáció terjedelme.) h. Az egy szállítótól való függőség csökkentése: ⇒ Az SSADM -ben jól elkülönített a logikai terv és a fizikai megvalósítási terv. A projekt idő 80% -at teszi ki A projekt idő 20% -at teszi ki Mire nem jó az SSADM ? • Nem alkalmas a szervezeti működés leírására, vagy annak tanulmányozására. • Nem alkalmas a szervezeti erősségek és gyengeségek vizsgálatára. • Nem alkalmas a siker tényezők vizsgálatára. • Nem alkalmas, csak egyes elemei a megvalósíthatóság elemzésére. A fejlesztés megindításához szükséges elemek 1. A projekt alapító okirat: ⇒ Funkcionalitás: a rendszertől elvárt funkciók rögzítése. ⇒ Az adatokra vonatkozó követelmények meghatározása. ⇒ A minőség mérését számszerűsítő adatok meghatározása. Célszerű minél globálisabb mutatókat találni. Ne magára a szoftver rendszerre határozzuk meg a követelményeket, hanem a felhasználó szemszögéből, a felhasználó tevékenységében észlelhető paraméterek (pl. válaszidő, megjelenítési idő.). 2. Logikai rendszerterv: ⇒ A működés eseményeinek leírása. ⇒ Definiálni kell a lekérdező műveleteket. ⇒ A felhasználói kölcsönhatások rögzítése. Azoknak a rendszer működési pontoknak a rögzítése, ahol a rendszer felhasználói beavatkozásra vár, ahonnan a rendszer működése a felhasználó beavatkozástól függően más-más működési ágon folyik.
A projekt alapító okirat és a logikai rendszerterv birtokában el kell dönteni, hogy a fejlesztés az SSADM módszertan alapján elvégezhető -e ? Az SSADM alkalmazhatóságának eldöntésére irányuló kérdések: A döntésre irányuló kérdésekre csak az "igen" válasz az amely az alkalmazhatóság igazolását jelenti. 1. Információkra vonatkozó kérdések: ⇒ A kezelendő információknak van-e szerkezet? ⇒ Lehet-e stabil logikai szerkezettel ábrázolni a kezelendő információkat? 2. Az eljárásokra vonatkozó kérdések: ⇒ Az elvégzendő eljárásoknak van-e elegendő szerkezete és pontossága modellt lehessen alkotni? ⇒ Lehet-e az adatfolyamra ábrát rajzolni? (Az a jó, ha a folyamatábrában nincsen egymást keresztező vonal, mert az nem kétdimenziós szerkezetre utal, hanem több dimenzióra.) ⇒ Melyek azok fejlesztési részek, amelyek általános és melyek azok, amelyek speciális szoftver eszközökkel kezelhetőek? Cél a meglévő szoftver eszközök minél hatékonyabb alkalmazása, kihasználása. ⇒ Mi a terjedelme az egésznek (fejlesztési terjedelem)? Kiterjedés, alprodzsektek meghatározhatóak-e?
Az SSADM jellemzői: • • • •
•
Az SSADM a szoftver fejlesztés analízis- és a tervezésfázisait fogja át (inkább az analízis területét). Az SSADM nagy súlyt fektet az egyes tervezési lépések eredményeinek folyamatos ellenőrzésére, valamint a leendő felhasználókkal történő konzultációkra. Az SSADM -ben az adatorientált megközelítés a fontos. A rendszerek fix magját az adatok és azok kapcsolatai alkotják. (Tapasztalat) szerint nagyobb eséllyel változik meg a feldolgozás módja, mint a feldolgozott anyag, adat. Az SSADM öt modulra, ezen belül hat szakaszra tagolódik. Az első három modul (a legelső vagy van vagy nincs nélkülözhető, de nem célszerű elhagyni) az elemzési modul, míg az utolsó kettő modul a tervezési modul. Az SSADM moduljai: I. Megbízhatósági-elemzés modul: ⇒0. Megvalósíthatóság eldöntése szakasz: Nem kötelező a végrehajtása. E szakaszban annak vizsgálata, hogy érdemes-e végrehajtani a fejlesztési projektet.? MEO! II: Követelmény-elemzés modul: ⇒1. A jelenlegi helyzet vizsgálata szakasz: a jelenlegi (fejlesztendő) rendszer logikájának a megismerése (folyamatok, adatok feltárása, követelmények rögzítése). MEO ⇒2. A rendszerszervezési változat kiválasztása szakasz: a fejlesztők és a felhasználó végleges döntése a változatok közül. MEO! III: Követelmény specifikáció modul (elemzés, előtervezés): ⇒3. Követelmények meghatározása szakasz: - adatokra: adatmodellek, - funkciókra: adatfolyam modellezés, - felhasználói interfész: prototipizálás, képernyőtervek, dialógusok. MEO! IV. Logikai rendszerspecifikáció modul: ⇒4. Rendszertechnikai változat kiválasztása szakasz: Több változat kidolgozása, majd a célra legmegfelelőbb kiválasztása. ⇒5. Logikai rendszertervezés szakasz: Feldolgozások logikai szintű tervezése (lekérdezések stb.). Dialógusok tervezése.
•
•
V. Fizikai rendszertervezés modul: ⇒6. Fizikai rendszertervezés szakasz: A modul olyan végterméket szolgáltat eredményül, amely a programozásra alkalmas. - Adattervek, - Feldolgozástervek, -Interfésztervek. Az SSADM részmodelljei: - adatok és kapcsolatok leírása: - adatok és tevékenységek kapcsolata, az adatok áramlása a tevékenységek között: - adatok, egyedek módosulásainak története: Logikai adatstruktúra diagram (LDS): A problémakörhöz tartozó egyedeket és kapcsolataikat ábrázolja. Logikai adatstruktúra diagram Egyedek
Kulcsszó
Könyv
Példány
Kapcsolatok
•
•
Egyedek fogalma: a problématerületen jelenlévő, egymástól megkülönböztethető személyek, tárgyak, események. Az egyedek között több típusú kapcsolat (egyedtípus)lehet. Egyedtípusok: ⇒Egy-egy kapcsolat: (Pl: ember-személyiszám) ⇒Egy-több kapcsolat: (Pl: ember-autó) ⇒Több-több kapcsolat: (Pl: színész-színdarab) Adatfolyam-diagram: az információk áramlását mutatja be. A diagram meghatározza a rendszer környezetét is, megadja, hogy milyen funkciók részei a rendszernek, illetve mely adatok származnak a környezetből. Az SSADM adatfolyam-diagramja funkciójában és formájában is rokon az SSA/DT rendszer DFD diagramjával. A két modell az egyes elemek jelölésrendszerében, illetve az adatok kijelölésében tér el. SSADM adatfolyam-diagram Érték
Modul 1
Kód
Kódellenőrzés
Kód
Összeg
Modul 2 Kódok
Kódállomány
Értékbekérés
Számlaállás Összeg
Számlaállomány Új számlaállás
Modul 2 Számlaellenőr zés
Szintaktika: - Tevékenységek: téglalap, benne tevékenység azonosítója és a tevékenység rövid tartalma. - Adatfolyam: nyíl, mellette megadva az áramló adat azonosítóját. Több szintű, felülről-lefelé irányuló szétbontást lehet megvalósítani. •
Egyedtörténet-diagram: a bekövetkező események hatására a rendszer adatainak megváltozását mutatja be. A diagram minden egyedre megadja az egyedhez tartozó
eseményeket, tevékenységeket és azok időbeli kapcsolatait. Az események alkothatnak szekvenciát, szelekciót és iterációt. Formalizmus azonos a struktúra-diagrammokéval. •
Egyedtörténet-mátrix: az egyedek - események (tevékenységek) közötti kapcsolatot összefoglalóan mutatja be. A mátrix jól szemlélteti, hogy egy adott egyed mely eseményekben vesz részt, illetve egy esemény mely egyedeket érint. A mátrixban az "X" szimbólum jelöli a kapcsolódó egyedeket és eseményeket.
•
Dialógusvázlat (LDO): lehetővé teszi az ember-gép kapcsolat, párbeszéd megtervezését. Minden interaktív eseményhez készítenek dialógusvázlatot. A vázlat elemei: - Adat; - Képernyő; - Tevékenység.
Az SSADM folyamatai • Megvalósíthatósági tanulmány: a fejlesztési projekt végrehajthatóságának a tisztázása. • Követelmények elemzése: annak felmérése, hogy mit kell az elképzelt rendszernek tudni. • Adatfolyam-diagram: annak ábrázolása, hogy melyik adat hová megy. • Követelményspecifikáció: a fejlesztendő rendszerrel szemben specifikált követelmények meghatározása. • A DFD, LDS és egyedtörténeti diagramok létrehozása. • Platform kijelölés: az adott (fejlesztendő rendszert) fejlesztést megvalósító operációs rendszer kijelölése (NOVELL, UNIX). • Platformfüggő specifikációk rögzítése: a kiválasztott OP. rendszernek megfelelő specifikumok rögzítése. • Adattervezés: • Normalizált adatok, relációs modell: • Algoritmus-tervezés: az egyes folyamatokat végrehajtó algoritmusok meghatározása. • Javított egyedtörténet-diagramok: • Programtervezés • Adatstruktúra, algoritmus-leírások Az SSADM módszertan kritikái: • •
A tervezett bonyolultabb rendszer nehezen modellezhető e módszerrel. Nem tartalmaz a módszer arra vonatkozó információkat, hogy miképpen fog a rendszer kommunikálni a környezettel. Erre kíván megoldást adni a módszer a dialógusvázlattal (LDO-val).
projektalapító okirat jelenlegi rendszer logikai adatmodellje
jelenlegi fizikai adatfolyammodell
követelményjegyzék
jelenlegi logikai adatfolyam modell
logikai ad attá
r-egyed m egfelelteté s
igényelt rendszer adatfolyammodellje
funkció meghatározás
B/K adatszerkezetek
attá i adtés ika lte loggfele me
d gye r-e
igényelt rendszer logikai adatmodellje
relációs adatelemzés
lekérdezések
rendszerszervezési alternatívák
egyedek
kimenetek
prototípusok
lekérdezési utak
események módosítások
eseményhatásábrák
egyedélettörténetek
egyed-esemény modellezés
rendszertechnikai alternatívák
mûveletek állapotjelzõk
dialógus tervezés
módosító feldolgozási modellek
lekérdezõ feldolgozási modellek
logikai adatfeldolgozás tervezése
funkció-komponens megvalósítási terv és program specifikációk
optimalizálás
folyamat-adat kapcsolat
fizikai adatbázisterv
teljesítmény elõrejelzések
Az SSADM folyamatai
Az SSADM eszközei: • Módszerek • Modellek • Technikák
Módszer: Három nézőpontból vizsgálja a kérdést. •
Funkciók szempontjából.
•
Események szempontjából.
•
Adatok szempontjából.
FUNKCIÓ FUNKCIÓ
Adatfolyam
Adattárak Események Egyedek
INFORMÁCIÓ
IDŐ Események
FELHASZNÁLÓI IGÉNYEK
RENDSZER MEGOLDÁSOK
Technikák: eljárásokat és termékeket keresünk. •
Megvalósíthatósághoz.
•
Követelmény elemzés.
•
Követelmény specifikáció.
•
Logikai rendszer specifikáció.
•
Fizikai rendszer tervezés.
Ezekhez kapcsolódnak a kiegészítő útmutatók
Az SSADM tervezési lépései a tervezés területei szerint:
Irányítási terület
Törzs SSADM
Technikai terület
Startégiai tervezés
Megvalósíthatóság
Becslés és mérés
Taktikai tervezés
Követelmény elemzés
Prototípus készítés
Infrastruktúra irányítás
Követelmény
Kapacitás tervezés
specifikáció Projekt irányítás Kockázatelemzés Konfiguráció kezeléss
Logikai rendszer
Elosztott rendszereket
specifikáció
alkalmaznak
Fizikai rendszer
Valós idejű rendszer
tervezés
3 GL és GL fejlesztő rendszerek
SSADM tervezési módszertan gyakorlati megvalósítása 530 db lépésből áll. Formalapok 1. Funkció típus lap: kötelező kitölteni. A lap tartalmi rovatai: - Módosító, vagy lekérdező. - Megvalósítás szerint: interaktív, vagy nem interaktív. - Kezdeményezés típusa szerint: a felhasználó, vagy a rendszer kezdeményezi a funkciót. - Funkció azonosító. (numerikus azonosító) - Felhasználói szerepkörök: - a rendszer felhasználók hozzáférési jogainak a meghatározása. - szerepkörök - funkciók hozzárendelése. - Funkció leírás. - Hibakezelés leírása. - A funkciók elemi folyamatainak a megnevezése.: - I/O leírások elkészítése. - a közhasznú folyamatok meghatározása. A közhasznú folyamat az, amelyet más funkció is használ. (PL.: nyomtató modul, kimeneti modul stb.) - Az események és funkciók meghatározása. - Esemény gyakoriság leírása. Meg kell határozni, hogy mely esemény vált ki egy másik
eseményt. Meg kell határozni, hogy mely esemény zár ki egy másik eseményt. - Meg kell határozni a be- és kimeneti adatszerkezeteket. - A funkciók használat gyakoriságának a meghatározása. - A lekérdezések tartalmának a meghatározása. - A lekérdezések gyakoriságának a meghatározása. - A szolgáltatási szintjére vonatkozó körülmények meghatározása. - célérték meghatározása, az elfogadhatóság számértékének rögzítése. Teljesítmény! Válaszképernyő megjelenítési ideje. 2. Követelmény specifikáció: - Meg kell határozni a célt. A felhasználói követelmények meghatározása, korlátok és jövőbeli kiterjesztésekkel. A követelmény meghatározás csoportosítási szempontjai: - Adatok: minden a rendszerben szükséges adat összeírása. - Funkciók: részletes folyamat specifikáció (mely folyamatokat szeretnénk megvalósítani.). - Felhasználói interfész meghatározásához a specifikáció prototipizálás technikáját ajánlja az SSADM. Segít e technika a felhasználónak tisztázni a szükséges felhasználói felülettel szembeni pontos követelményeket. Melyek azok az adatszerkezetek, kapcsolatok, amelyeket szeretne látni a felhasználó. Ennek a lépésnek az eredményeként alakulnak ki a képernyőtervek, a dialógusok és menük. - Minőségi követelmények meghatározása. Azoknak a fejlesztői és felhasználói kritériu mok meghatározása, amelyek a megfelelőség elfogadásához szükségesek. - A KÖVETELMÉNY JEGYZÉK megfelel-e a szabványoknak. Illeszkedik-e az információ stratégiához. Megfelel-e az alapító okiratban rögzített elvárásoknak. Elfogadták- e a felhasználók a követelményjegyzéket. Összeegyeztethető e a követelmény specifikáció a helyi eljárásrendekkel. A kiindulási alap követelmény specifikáció megvalósítása lehetséges-e. Minden érintett személlyel konzultáltak-e. Valóban pontos és teljes képünk van-e rendszer kiterjedéséről. A követelmények kölcsönösen megfelelnek-e egymásnak (ha nem felelnek meg - prioritási sorrend.). Az adatjegyzék összeegyeztethető-e a tervezett rendszer logikai adatmodellével. A mennyiségi adatok megfelelnek-e az előírásokban szereplő, elérési utakban szereplő előírásokkal. A követelményjegyzés és a funkciójegyzék kölcsönös hivatkozásai megfelelnek-e. A funkciók teljes körűen támogatják-e a szerepükhöz tartozó feladatokat. - LEKÉRDEZÉSEK: A lekérdezésekhez van-e funkció leírás. Vannak-e a feldolgozásoknak leírásai. Formális szemle !!! Hivatkozási, ellenőrzési pontok: •
Követelmény meghatározása (310-es lépéstől kezdődik).
•
Adatfolyam modell ellenőrzése (310-es lépés).
•
Dialógus tervezés (három helyen. (310, 530 lépés)
•
Logikai adatmodell (320-as lépéssorozat).
•
Funkció meghatározás (330-as lépéstől kezdődik).
•
Relációs adatelemzés (340-es lépéstől kezdődik).
•
Specifikus prototípus kidolgozása (350-es lépéstől kezdődik).
•
Egyed-esemény modell kidolgozása (360-es lépéstől kezdődik).
•
Rendszertechnikai alternatívák kialakítása (410, 420-as lépéstől kezdődik).
•
Logikai adatfeldolgozási terv összeállítása (540-as lépés sorozat).
