1 / 130

A rendszerfejlesztés technológiája

A rendszerfejlesztés technológiája. Előadásvázlat. 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.

izzy
Download Presentation

A rendszerfejlesztés technológiája

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related