Szoftvertechnológia

1. Szoftvertechnológia Gyurkó György Megjegyzés: A 2-10. lap új anyag. A 11-36. lap olyan ismétlés a gazdasági informatika alapjai tárgyból, amely az objektumorientált elemzés és tervezés kurzus keretében is számon lesz kérve.

2. Technológiai célok és megoldások

3. A szoftvertechnológia általános célja • Kezelhetővé tenni a bonyolult (összetett) problémákat. • Javítani a szoftver fejlesztési és megtérülési minőségi jellemzőit.

4. Komplex probléma kezelhetővé tétele • Bármilyen bonyolult is a probléma egésze, annak megoldása olyan út(hálózat) bejárásával produkál-ható, amelynek végül minden csomópontjában csak egyszerű problémákat kell megoldani. • A feladat egésze csoportmunkában is elvégezhető, azaz felosztható a csoport tagjai által nagymérték-ben függetlenül megoldható részfeladatokra.

5. Szoftvertechnológiával befolyásolható szoftverminőségek (Fejlesztési és megtérülési minőségek) • elemezhetőség, • változtathatóság, • tesztelhetőség, • stabilitás, • hordozhatóság, • újrafelhasználhatóság.

6. Technológiai megoldások • Modularizáció „Osztd meg és uralkodj!” • A független problémák megoldásának elkülönítése.

7. Modularizáció - „Osztd meg és uralkodj!” A probléma (a termék) olyan építőelemekre (modulokra) bontása, amelyek • a környezetük számára fekete dobozok (absztrakció: részletek elrejtése); a környezet csak a stabil felületüket (interfész) ismerheti. • a rendeltetése egymagában megérthető, meghatározható; • önállóan (elkülönülten) tervezhető, kivitelezhető, tesztelhető; • a modulokból a célul kitűzött rendszer felépíthető, a rendszer működése a modulok megfelelő együttműködé-sével produkálható. Többszintű, azaz hierarchikus modularizáció (felbontás).

8. Kitérő: Itt mit jelent az absztrakció? Az absztrakció itt két jelentést hordoz: összetettséget és elrejtést. • A modulok olyan – a szakterület jelenségeihez, a rendszertől elvárt szolgáltatásokhoz közelebb álló – összetett műveletek, amelyekből a rendszert könnyebb összerakni, mint a programnyelv elemi művele-teiből. Ugyanakkor egy-egy modult, egy-egy szűkebb szoftverépítő-elemet sokkal egyszerűbb kifejleszteni, mint a rendszer egészét. • A modul az elrejtés eszköze, amennyiben a külvilágnak (más modulok-nak, a rendszer egészének) elegendő annyit tudni róla, hogy mit csinál (milyen adatokat vár, illetve milyen adatot szolgáltat), és csak a modul-ra tartozik, hogy hogyan csinálja. (Tömörebben: a modul a környezete számára fekete doboz.) Ennek az az előnye, hogy a modul belseje (a megoldás módja) anélkül módosítható, hogy az kihatással lenne a más modulokkal való együttműködésére. (Karbantarthatóság.)

9. A hierarchikus modularizáció következményei(a feladat „megszelídítése”) • A rendszer egészének szintje: • Kevés elem (néhány nagyobb modul) és kevés kapcsolatot (az említett modulok közötti kapcsolatokat). • A modulok fekete dobozok: érdektelen, hogy belül hogyan működnek, csak az a lényeg, hogy a rendeltetésük szerint elfogadható megszólításra (inputra), a rendeltetésük szerinti választ (outputot) adjanak. • A modul belseje a többi modul számára észrevétlenül cserélhető, ha a környezet felé mutatott felülete nem változik. • Összetett modul szintje:mint a rendszer szintje. • Elemi modul szintje:Minden részletével együtt könnyen átlátható. • Nincs akadálya a csoportmunkának, a felsorolt tulajdonságú modulok kivitelezése szétosztható egy csoport különböző tagjai között.

10. A független problémák megoldásának elkülönítése • A szoftver komponenseit (építőelemeit) úgy kell kijelölni, hogy adott probléma megoldásáért felelős (egyszerű vagy összetett) szoftverépítőelem mindig egyértelműen azonosítható legyen. • Ha két probléma egymástól függetlenül is felmerülhet, vagy az egyik probléma megoldására vonatkozó köve-telmények a másik probléma megoldására vonatkozó követelményektől függetlenül megváltozhatnak, akkor ezen két probléma megoldása nem lehet egyetlen bonthatatlan építőelem feladata.

11. Az ismertetett technológiai megoldások hogyan javítják fejlesztési és megtérülési minőségeket? • Elemezhetőség? • Változtathatóság ? • Tesztelhetőség? • Stabilitás? • Hordozhatóság? • Újrafelhasználhatóság?

12. Megközelítési módok és módszertanok

13. A (szoftver)fejlesztési megközelítési mód egy sajátos absztrakciós szemlélet, amelyből sajátos • fogalomrendszer, • eszköztár, • elemzési (felbontási) és konstrukciós elvek • következnek. • A (szoftver)fejlesztési módszertan a fejlesztési folyamat minden architekturális összetevőjét lefedő, a kidolgozók által figyelembe vett célkitűzések és feltételek mellett legjobb gyakorlatnak szánt • terméksémák, • folyamatsémák és • szervezeti sémák, • valamint a felsoroltakhoz kapcsolódó • értékelési (mérési) kritériumok • együttese.

14. Megközelítési módok • Moduláris • Strukturált • Objektumorientált

15. Módszertanok Alaptípusok: • Folyamatvezérelt • Eseményvezérelt • Adatvezérelt • Felhasználóvezérelt Az előbbieket kombináló kevert típusok: • Hagyományos • Objektumorientált

16. A szoftverfejlesztés folyamata

17. Az IR fejlesztésének főbb tevékenységei Ezek minden életciklusmodellben megjelennek: • Elemzés • Tervezés • Megvalósítás, tesztelés, integráció • Bevezetés

18. Elemzés Cél a követelmények meghatározása • A létező rendszer folyamatainak megfigyelése, elemzése • Dokumentumok tanulmányozása • Kérdőíves felmérés • Interjúk a szakterület specialistáival, a felhasználókkal Termékek: • Elemzési modellek • Követelményleírások • Rendszerszervezési változatok

19. Rendszerszervezési változat A követelmények olyan részhalmaza, amely • a projekt korlátai mellett teljesíthető és • konzisztens (ellentmondásmentes és hivatkozásteljes) Megjegyzés: Kivételesen a fejlesztés (tervezés, megvalósítás) alatt megengedhetők ellentmondó követelmények is, de legkésőbb a szoftver telepítésekor el kell dönteni, hogy közülük melyik érvényes. Tehát ilyenkor a szoftvert fel kell készíteni a telepítési időre halasztott – és már a felhasználó által hozott - döntések fogadására.

20. Tervezés A szoftvertervezés termékei: • szakterületi (termék)modell:a szakterület fogalmainak, objektumainak, viszonyainak közvetlenül megfeleltethető absztrakciókat tartalmazó modell; • architektúramodell:a tervezés és a megvalósítás struktúráját és követendő mintáit és az architekturális komponensek interfészeinek specifikációit tartalmazó modell; • termékterv:nagyvonalú rendszer-, illetve szoftverterv, funkcionás modulok között interfészek specifikációk, valamint részletes szoftverterv; • tesztspecifikációk:egységtesztekre, integrációs tesztekre, validáló tesztelésre; • megoldásmodell:az architektúramodellt maradéktalanul érvényesítő részletes szoftverterv.

21. Tervezés / 2 A szoftvertermék elemezhetőségét, változtathatóságát, tesztelhetőségét, stabilitását, hordozhatóságát, valamint a komponenseinek újrafelhasználhatóságát szolgáló alapvető tervezési (konstrukciós) elv: Egymástól függetlenül előforduló problémákat nem szabad egyazon megbonthatatlan építőelemben megoldani!!! A problémák függetlenségének felismerését segítő osztályozási szempontok: • szintek és vetületek - a strukturált megközelítés szerint; • szintek, rétegek és minőségek – a korszerűbb módszertanokban.

22. A szoftvertervezés szintjei és vetületeia strukturált megközelítés szerint

23. Egy finomabb rendszerezés:A SunTone módszertan architektúra-sémája Az alkalmazás minden építőeleme egy meghatározott szintbe, illetve rétegbe sorolható, és egy meghatározott minőségért felel.

24. Az elemzés és tervezés technikái, eszközei Grafikus modellezési technikák: • tömörség, • egyértelműség CASE (Computer Aided Software Engineering) eszköztár: a grafikus modellezési technikák integrált támogatása

25. CASE eszköztár használatának előnyei • Redundanciamentes terv • Bizonyos tervezési-szintaktikai hibák automatikus kizárása • A modellek konzisztenciájának ellenőrzése • Iparági szabványnak számító technológia használata • Csoportmunka támogatása • A követelmények változásának és teljesülésének követhetősége • Változáskezelés • Az adatbáziskód (SQL) generálása (100%) és a programkód generálása (részben) • Reengineering • Dokumentációgenerálás

26. A fejlesztés további tevékenységei Kivitelezés (kódolás és egységtesztek) Integráció és integrációs teszt Minőségi teszt Szoftver telepítése, bevezetése a használatba • a szervezeti folyamatok újraszervezése – a szoftver szakmai felhasználási környezetének kialakítása; • a szoftver testreszabása; • az üzemeltetési, technikai környezet kialakítása, a rendszer üzemeltetési környezetbe telepítése; • adatmigráció, azaz a korábbi rendszer adatainak konvertálása és betöltése az új rendszer adatbázisába; • a felhasználók kiképzése; • próbaüzemi teszt, azaz üzemi környezetben tényleges volumenek és csúcsterhelés melletti teszt; • átállás az új rendszerre

27. Fejlesztési életciklusmodellek

28. Vízesés modell

29. Vízesés modell / 2 • Előnyei:- Világos struktúra. - A projekt egyszerűen ütemezhető, irányítható. • Hátrányai:- Csak a szakaszok végén van visszacsatolás. - Feltételezi, hogy a követelmények pontosan ismertek és nem változnak. - Hosszú a fejlesztési idő.

30. V modell

31. V-modell / 2 • Előnyei / hátrányai:- Többnyire azonosak az egyszerű vízesés modellével. - Az egyszerű vízesés modellnél világosabb képet ad arról, hogy adott tevékenység és annak terméke mely korábbi tevékenység termékének kell megfeleljen.

32. Iteratív fejlesztés / 1 Iteráció: Azonos tevékenység vagy tevékenységsor ismételt végrehajtása. Iteratív fejlesztés: Minden iteráció újabb minőséget ad az előző végrehajtás termékéhez. - Az iterációkat határozott célkitűzés, átfogó projektterv előzi meg. • Nem önálló modell, hanem egy olyan, a célt fokozatosan közelítő megoldás, amelyet klasszikus életciklusmodellekkel kombinálva új életciklusmodellt kapunk. • Iteratív fejlesztésen alapuló nevezetes modellek: • az inkrementális modell • a spirálmodell

33. Iteratív fejlesztés / 2 • Az iteratív fejlesztés motivációi: • kezelni, hogy kezdetben nem lehet ismert minden követelmény; • számolni az ismert követelmények megváltozásával; • különlegesen nagy kockázatú projekteket is kezelhetővé tenni (lásd spirálmodell); • minél korábban szülessen egy működő, átadott verzió (lásd inkrementális modell); • az előző iterációk során szerzett tapasztalatok felhasználásával a módszerek, a termékminőség folyamatos javítása (inkrementális modell); • megbízhatóbb termék (inkrementális modell: előbbi következménye; spirálmodell: kifejezetten a minőségi kockázatok csökkentését célzó prototípusok).

34. Inkrementális modell - átlapolással

36. Inkrementális modell előnyei, hátrányai Előnyei: • Kezelni tudja a követelmények változásait. • Korán megszületik egy működő, átadott verzió (ez a projekt megítélése, a megrendelő elégedettsége szempontjából nagyon fontos); • Az előző verziók fejlesztése és használata során szerzett tapasztalatok felhasználásával a módszerek folyamatosan javulnak, a követelmények finomodnak, a kockázatok csökkennek. • A későbbi verziók egyre megbízhatóbbak (több tapasztalat, több sokszorosan kipróbált komponens a termékben). • A teljes rendszer helyett csupán egy inkrementumot fejlesztő projekt akkor is elindítható, ha a szervezet szűkösebb emberi és pénzügyi erőforrásokkal rendelkezik. • Elegendő erőforrások birtokában viszont az inkrementumok fejlesztésének átlapolásával a teljes rendszer fejlesztésének időtartama is csökkenthető. Hátrányai: • Szűkös erőforrások esetén a teljes rendszer lassan készül el. • A soklépéses folyamat és a párhuzamos tevékenységek irányítása nehéz feladat. • A már működő részeket és a későbbi lépések eredményeit újra és újra integrálni kell.

37. További életciklusmodellek • Az iteratív fejlesztés valamilyen változatai (pl. Boehm-féle spirálmodell) • A kombinált iteratív-inkrementális modell változatai (pl. a Rational Unified Process – RUP-modell) • A felhasználó és a fejlesztő közötti jobb megértést, a követelmények pontosabb meghatározását, valamint a fejlesztés gyorsítását szolgáló modellek (pl. egyszerű prototípusmodell és annak evolúciós fejlesztés nevű változata) • A követelmények megváltozásával szemben különösen toleráns modellek (pl. agilis módszertanok - extrém programozás) • A ráfordítások – megvásárolható kész komponensek beépítésével való – csökkentő modellek (komponens alapú fejlesztés) • Az esetleges minőségi hiányosságok katasztrofális következményeinek kockázatát módszeresen csökkentő modell (pl. Boehm-féle spirálmodell)