A rendszerfejlesztés technológiája

1. A rendszerfejlesztés technológiája Előadásvázlat

2. A szoftver A szoftver a programok, az adatok és a dokumentációk együttese, nem csak maga a program. Adatok alatt a szoftver vásárlásakor kapott állományokat kell érteni: ilyenek pl. a telepítő és a konfigurációs állományok.

3. A szoftver egy termék • bizonyos funckiót szolgáltat(szolgáltatási funkció) • határidőre kell előállítani(előállítási határidő) • előállításának van költsége (előállítási költség) • minőségi elvárásoknak kell megfelelnie(minőségi elvárások)

4. Szerzői jog - szabadalom • Automatikusan jár, ingyenes – bejegyzése, fenntartása országonként díjhoz kötött, a szabadalmi per is drága • Szerző halála után 70 évig, utána közkincs – 20 évig • Szellemi termékekre – találmányokra

5. A szoftverek csoportjai • 1. általános célú (dobozos; COTS = Commercial On The Self) szoftvertermékek • bárki megvásárolhatja • általában sok év fejlesztőmunkája van mögötte • általában nagy szoftverek • a szakértelmet és a befektetett energiát kell megfizetni • pl.: az Oracle adatbázis-kezelő rendszere

6. A szoftverek csoportjai • 2. Célszoftverek • megrendelésre készülnek • a kifejlesztést kell megfizetni • pl.: a Neptun egységes felsőoktatási tanulmányi rendszer

7. Új módszerek Az információs rendszerek fejlesztéséhez, a szoftvertechnológiához, a szűkebben vett információ oldali részhez a kitalálás óta két új dolog csatlakozott: • minőségbiztosítási módszerek a szoftverek kifejlesztéséhez; • projektvezetési, -irányítási, -szervezési módszerek a fejlesztést végző emberek munkájának menedzselésére

8. A szoftver, mint termék előállítása tevékenységsorozatban • specifikáció: az elvárásokat tárjuk fel, konkretizáljuk, rögzítjük • elkészítés/implementáció • validáció: az elkészült szoftverről belátjuk, hogy megfelelő • szoftverevolúció: az elkészült szoftver módosítása, továbbfejlesztése (nem hibajavítás!)

9. A szoftverfejlesztés rendszerszervezési elemei • elemzés (analízis), • tervezés, • implementáció, • követés.

10. Absztrakt megközelítés A szoftverfejlesztési életciklusban egy abszrakt megközelítéstől egy teljesen konkrét megközelítés felé megyünk el valamilyen módon, valamilyen alkalmazott tevékenységsorozat folyamán.A cél ezt a tevékenységsorozatot abba az irányba tolni, hogy minél hamarabb, minél absztraktabb módon megfogalmazott dolgokból tudjuk a konkrét dolgokat automatikusan létrehozni.

11. A folyamat • a követelmények meghatározása és elemzése • tervezés • alrendszerek fejlesztése • rendszerintegráció • a rendszer telepítése • a rendszer működtetése • rendszerevolúció • a rendszer üzemen kívül helyezése

12. A szoftverfejlesztés folyamatának kiegészülése Minőségbiztosítás és projektmenedzsment Fő célok: határidők meghatározása, melyik lépést mikorra kell végrehajtani; szükséges hardver-, szoftver-, emberi, és anyagi erőforrások biztosítása; az emberek munkájának irányítása, az erőforrások szétosztása, határidők biztosítása stb.

13. A követelmények meghatározása és elemzése • funkcionális követelmények: rendszerszolgáltatások, pl.: tantárgyfelvétel, jegybeírás stb. • rendszertulajdonságok: a rendszer egészére jellemző dolgok, pl.: rendelkezésre állás, biztonságosság, felhasználói felület • lehatárolás: a rendszernek mit nem kell tudnia

14. Alrendszerek interfészének definiálása Követelmények felosztása Alrendszerek funkcionalitásának meghatározása Alrendszerek azonosítása Követelmények alrendszerekhez rendelése Tervezés A tervezés során a követelményektől eljutunk valamilyen módon az alrendszerekig.

15. Alrendszerek fejlesztése • Az alrendszerek általában párhuzamosan fejlesztendők, fejleszthetők. Az egyes alrendszereken dolgoznak az egyes fejlesztői csapatok; tervezés után fejlesztik, implementálják, kódolják, majd tesztelik az egyes alrendszereket. Ennek eredményeképpen előállnak az alrendszereink.

16. Rendszerintegráció • A kifejlesztett alrendszerekből összeállítjuk a teljes rendszert. Előfordulhat, hogy bizonyos alrendszereket nem fejlesztünk, hanem megvesszük. Bár a rendszerintegrációnál feltesszük, hogy az egyes alrendszerek önmagukban jól működnek, a rendszer összeállítása sok gondot okozhat.

17. A rendszer telepítése • Ha a rendszerfejlesztő cég és a megbízó jónak látja az elkészült rendszert, akkor következik a rendszer telepítése. A kifejlesztett rendszert konkrét hardver és szoftver platformra kell telepíteni.

18. A rendszer működtetése • A rendszer működtetése során derülnek ki a problémák, amire nem gondolt a felhasználó, működés közben ezeket a problémákat orvosolni kell. Ki tegye mindezt? Ez főnök vagy szerződés kérdése. Nagyon fontos a felhasználók képzése; a felhasználókat el kell látni információval.

19. Rendszerevolúció • A rendszert módosítjuk, továbbfejlesztjük a felhasználói környezet, a törvényi szabályozás, a cég méretének stb. megváltozása miatt. Tehát természetes fejlődés megy végbe a szoftvereknél is, amelynek semmi köze nincs a hibákhoz. Tervezéskor figyelembeveendő.

20. A rendszer üzemen kívül helyezése • Az információs rendszer általában nem önmagában létezik, hanem további rendszerek környezetében dolgozik: más rendszerektől adatokat fogad, más rendszereknek adatokat szolgáltat. • A végiggondolt rendszerevolúció oda vezet, hogy nem a teljes rendszert állítjuk le, csak a rendszernek bizonyos részeit, bizonyos alrendszereket cserélünk le

21. Szabványok • tényleges, törvényszintű (de jure) szabványok: szabványügyi szervezetek (ISO, ANSI) dolgozzák ki őket • ipari (de facto) szabványok: a szakterület vezető cégei összeállnak és alkotnak valamilyen formációt, konszenzusra jutnak, és ezt nyilvánosságra hozzák. (W3C) • piaci szabványok: olyan szakterületeken alakulnak ki, amelyeken van egy nagyon erős piaci cég, őhozzá igazodnak a többiek

22. Folyamatmodellek • vízesés modell • evolúciós modell • formális fejlesztési modell • újrafelhasználás-alapú modell • iteratív modellek • spirális fejlesztési modell • inkrementális fejlesztési modell

23. követelmények meghatározása rendszer- és szoftvertervezés implementáció és egységteszt működtetés és karbantartás Vízesésmodell • Az első folyamatmodell, amely a történelemben kialakul, 1970-ben definiálták. Ez más termékelőállítási folyamatmodellből származik.

24. Vízesésmodell • Előnyei: • a legegyszerűbb, a legjobban alkalmazható modell • kicsi és közepes méretű rendszereknél jól struktúrált, jól felépített, jó architekturális jellemzőkkel rendelkező, robusztus rendszer fejleszthető • Hátrányai: • Merev, nem flexibilis egymásraépülés. • Minden egyes folyamat teljeskörűen lezárul, mielőtt a következő folyamat elindulna. • A legutolsó lépésben derülnek ki a korai lépések problémái: nem teljesített követelmények, félreértések, stb.

25. specifikáció kezdeti verzió vázlat leírása fejlesztés közbülső verziók validálás végleges verzió Evolúciós modell • A 80-as évek elején találták ki, párhuzamos fejlesztési modell, implementációk verzióin keresztül jutunk el a végső verzióhoz: verziósorozatot produkál

26. Evolúciós megközelítések • feltáró fejlesztés: a felhasználó és a fejlesztő közösen finomítja a követelményeket • eldobható prototípuskészítés:a felhasználó kipróbálja a prototípust, így rájöhet, hogy mit akar.

27. Evolúciós modell • Előnyei • Nagyon hamar kap kipróbálható verziók • A felhasználó hamar rájöhet, hogy a követelmények jók vagy nem • Hátrányai • A túl sok verzió áttekinthetetlenné válhat • Nem robusztusak: általában rossz struktúráltságú, architektúrájú szoftverhez vezet. • Gyors fejlesztést, rapid techikákat igényel

28. követelmények meghatározása formális specifikáció formális transzformáció integráció és rendszerteszt rendszer-validáció Formális modell • A 70-es években alakult ki a vízesés modell egy változataként. A közbenső rész más: a rendszerspecifikációból matematikai eszközökkel formálisan generálunk működő programot. A transzformációs folyamata formálisan megadott követelményekből előállít egy adott nyelvű kódot.

29. Formális modell • Előnye: • automatizált a folyamat; bármilyen rendszer esetén alkalmazható • biztonságkritikus rendszerek esetén alkalmazzák • Hátránya: • a rendszerkövetelmények formalizálása kézzel kell, hogy történjen

30. követelmények specifikációja komponens-elemzés követelmények módosítása rendszerterv újrafelhasználással fejlesztés és integráció rendszer-validáció Újrafelhasználás-orientált modell • Léteznek olyan komponensek, amelyeket újrafelhasználhatunk (kód, tervezési szinten)

31. Újrafelhasználás-orientált modell • Hátrány: kompromisszumok, leromolhat a rendszer struktúrája • Előnyök: idő, pénz megtakarítása; a komponensek kipróbáltak, teszteltek stb., így egyfajta biztonságérzetet nyújt, sok validációs lépést megspórolhatunk.

32. Iteratív folyamatmodellek:inkrementális fejlesztési modell • A fejlesztés inkremensekben történik, az inkremenseket építünk, inkremensekkel bővítjük, és ha szükséges, nyilván megismételjük az inkremenshez akár a specifikációs tervezés lépését is.

33. vázlatos követelmények meghatározása követelmények inkremensekhez rendelése rendszer- architektúra megtervezése rendszer-inkremens fejlesztése inkremens validálása inkremens integrálása rendszer validálása végleges rendszer a rendszer nem teljes Inkrementális modell

34. Inkrementális modell • Előnyei: • inkremensek kicsik, jól körülhatárolhatók, adott esetben a követelmények egyértelműen specifikálhatók • az inkremensek fejlesztése történhet párhuzamosan • kezdhetjük a legfontosabb inkremensekkel, a felhasználó nagyon hamar kap egy nem eldobható prototípust, • a rendszerfejlesztés kockázata kisebb • a rendszerfejlesztés közben a hibák hamarabb kiderülnek

35. Spirális modell • 1. lépés: célok meghatározása • 2. lépés: kockázatelemzés, kockázatok felismerése, megszüntetése • 3. lépés: fejlesztés és validálás • 4. lépés: áttekintés, döntés a folytatásról

36. Spirális modell • Előnyei: • foglalkozik a kockázatokkal • sokkal szisztematikusabban foglalkozik a projekttel • Hátrányai: • nem a legtriviálisabb modell • nagy rendszereknél javallott

37. KÖVETELMÉNYEK MEGHATÁROZÁSA, ELEMZÉSE • A követelmények osztályozása • felhasználói követelmények • rendszerkövetelmények • szoftverterv-specifikáció

38. A követelmények osztályozása • funkcionális követelmények: hogyan reagál a rendszer bizonyos inputokra, bizonyos bekövetkező szituációkra, teljes és ellentmondásmentes • nem-funkcionális követelmények • szakterületi követelmények

39. A követelmények kiknek szólnak • A felhasználói követelményekkel elsősorban a fejlesztői oldali és a megrendelő oldali menedzserek találkoznak. • A rendszerkövetelményekkel a rendszerfejlesztők, az informatikusok találkoznak. • A szoftverterv specifikáció nyilvánvalóan a szoftver tervezőinek alapvető fontosságú.

40. Követelmények másik felosztása • funkcionális követelmények: hogyan reagál a rendszer bizonyos inputokra, szituációkra, kivételek feltárása • nem-funkcionális követelmények: általános, teljes rendszerre vonatkozik • szakterületi követelmények

41. nem-funkcionális követelmények termék- követelmények szervezeti követelmények külső követelmények hatékonysági követelmények megbízhatósági követelmények hordozhatósági követelmények együttműködési követelmények etnikai követelmények használhatósági követelmények telepítési követelmények implementációs követelmények szabány- követelmények törvényi követelmények teljesítmény követelmények tárterület követelmények biztonsági követelmények adatvédelmi követelmények Nem funkcionális követelmények

42. A funkcionális és nem-funkcionális követelmények elválasztása • ha együtt kezeljük, túl nagy lesz a specifikáció, nem veszünk észre bizonyos követelményeket; validációnál a bonyolultság miatt bizonyos követelmények elsikkadhatnak. • ha külön kezeljük, akkor nehéz az ellentmondások felderítése

43. Követelmények dokumentációja • természetes nyelv • diagramok (UML) • leíró nyelvek: programnyelvekhez hasonló • matematikai specifikáció • hibrid megoldás

44. Rendszermodellek • környezeti modellek (HOL) • viselkedési modellek (HOGYAN) • adatmodellek (MIVEL)

45. biztonsági rendszer központi számlázór. számla- adatbázis bankautomata rendszer központi nyilvántartór. Igénybevételiadatbázis karbantartó rendszer Környezeti modellek • A rendszer határainak felderítése

46. Viselkedési modellek • adatfolyam modellek: tipikus struktúrált modellek • állapotátmenet modellek: tipikusan OO-modellek (adatfolyam modell az OO-ban nincs)

47. Adatfolyam modellek • Az adatfolyamok hogyan mozognak, hogyan áramlanak a rendszeren belül, hogyan kerülnek feldolgozásra. • Jelölések: ellipszis: feldolgozás, ezek egy-egy függvénynek tekinthető, amely a beérkező adatokból legenerálja a kimenetet és továbbítja. • Nyíl: az adatáramlás irányát jelölik, az adatok milyensége a nyilakra van írva. • Téglalap: adattárolók; ezek állományok, adatbázisok; itt megőrzésre kerülnek az adatok és újra elővehetők.

48. továbbítás szállítóhoz átvizsgált és aláírt megren- delő űrlap aláírt megren- delő űrlap megrendelés részletei + üres megrendelő űrlap kitöltött megrendelő űrlap kitöltött megrendelő űrlap kitöltött megren- delő űrlap megrendelés validálása megrendelés rögzítése megrendelés részletezése aláírt megren- delő űrlap megrendelés-állomány költségkeret módosítása megrendelés végösszege + számla rögzítése költségvetés-állomány Adatfolyam modell példája

49. Állapotátmenet modell • A formális automata, mint absztrakt matematikai eszköz megjelenése a formális rendszerfejlesztésben. • Ha túl bonyolult a rendszer, bizonyos állapotokat metaállapotnak tekintve külön állapotátmenet diagramon ki lehet fejteni.

50. Adatmodellek • Az adatok struktúráját írják le, az egyedek tulajdonságait, és az egyedek közötti kapcsolatokat modellezik.Ezen modellek vezetnek az objektum modellek kialakulásához a 90-es évek elején. • ETK, ER, OO adatmodellek