A SZOFTVERTERVEZÉS GYAKORLATI OKTATÁSA. Katona Krisztina, Kurdi Zsombor Zsolt Budapesti Műszaki Főiskola Neumann János Informatikai Kar.

Átírás

1 A SZOFTVERTERVEZÉS GYAKORLATI OKTATÁSA TEACHING HOW TO DESIGN SOFTWARE SYSTEMS IN PRACTICE Katona Krisztina, Kurdi Zsombor Zsolt Budapesti Műszaki Főiskola Neumann János Informatikai Kar Összefoglaló! A mérnök informatikus képzésben a szoftvertervezés (szoftvertechnológia) elméleti oktatása mellett kiemelten fontos a megfelelő gyakorlat elsajátítása is. A szoftvertechnológia a nagyméretű programrendszerek előállításával foglalkozik, amelyek elkészítése messze meghaladja egy ember munkáját, ezért nagyobb létszámú csapatok végzik a fejlesztést. A programozási nyelveket és technikákat oktató tárgyak az alapvető programozási ismeretek elméletének és gyakorlatának átadására szorítkoznak, ám a diplomát szerzett mérnököktől az őket foglalkoztató cégek elvárják, hogy a szoftverkészítési (programozási) ismeretek mellett a szoftvertervezés témakörében is megbízható gyakorlati tudással rendelkezzenek, képesek legyenek csoportban dolgozni, a csoport munkájába bekapcsolódni és esetenként azt koordinálni; értelmezni és módosítani tudják a már elkészült terveket és képesek legyenek teljesen új szoftverek tervezésére és elkészítésére. Ezért tartjuk fontosnak a szoftvertechnológia gyakorlati oktatása során a tervezési és programozási feladatok csoportokban történő megoldását. Az előadásunkban ismertetjük a Budapesti Műszaki Főiskola Neumann János Informatikai Karán a 2007/2008. tanév tavaszi félévében tartott Szoftvertechnológia gyakorlat tárgy oktatása során a gyakorlati ismeretek elsajátításához felhasznált tananyagot és az oktatás során szerzett tapasztalatokat. Kulcsszavak szoftvertechnológia, UML, RUP Abstract Software Engineering is an important part of IT engineer education, which has to contain theory and practice topics as well. Software Engineering defines techniques and methods for design, implement, test and maintain software systems are produced by larger teams. Subjects about programming languages contains only basic programming knowledge, but a graduated engineer should have practical experience in software design, team work and project management. That is the reason why we deem important to practice designing and implementing large software systems in teams during the software engineering courses. This article introduces the course material and our experiences in teaching software engineering in practice at Budapest Tech John von Neumann Faculty of Informatics. Keywords software design, UML, RUP 1

2 1. Bevezető Az informatika különösen a programfejlesztés felsőfokú oktatásában alapozó szerepet játszanak az algoritmusokat, adatszerkezeteket, programozási technikákat és a különböző programozási nyelvek szintaxisát és szemantikáját oktató tárgyak. Az itt megszerzett ismeretek alkalmassá teszi a hallgatókat, hogy egyszerű problémákra megbízható és hatékony szoftveres megoldásokat készítsenek. Napjainkban az ipari alkalmazások jelentős hányada olyan szoftverrendszer, amely mérete és komplexitása megköveteli, hogy a megvalósítást alapos tervezés előzze meg és a programfejlesztés csoportmunkában történjen. Ezért az informatika felsőfokú oktatásában nagy hangsúlyt kell fektetni a szoftvertervezési módszerek elméletének bemutatására és ezen elméleti ismeretek gyakorlati alkalmazási készségének átadására. Cikkünkben a Budapesti Műszaki Főiskola Neumann János Informatikai Karán a Szoftvertechnológia gyakorlat című tárgy oktatásában szerzett négy éves tapasztalatunkat foglaljuk össze, kiemelve az elmúlt félévben eszközölt változtatásokat, amelyek segítségével a hallgatók átfogóbb gyakorlati ismereteket szerezhetnek a szoftvertechnológia témakörében. A következő szakaszban bemutatjuk az oktatott szoftverfejlesztési módszertant, amely után bemutatjuk a gyakorlatok felépítését a változtatások bevezetése előtti években. Ezt követi az új tematika bemutatása. Végül összefoglaljuk az elmúlt félévben szerzett tapasztalatainkat. 2. Szoftverfejlesztési módszertan A szoftver termék gyártásának folyamatát a szoftverfejlesztési módszertan határozza meg. Egyszerűen nézve a módszertan egy eljárás, amely a felhasználói igényeket működő szoftverrendszerré transzformálja. Valójában egy jól kidolgozott szoftverfejlesztési módszertan ennél több: egy általános és fejlődőképes szabályrendszer, amely a szoftver előállításának folyamata során minden résztvevő számára meghatározza, hogy mit kell tennie ahhoz, hogy elérje a kívánt célt, amely cél résztvevőnként más és más lehet. Egy jó szoftverfejlesztési módszertan alapjait a korra jellemző technológiák, a szoftverfejlesztéshez használt eszközök, a folyamatban résztvevők tudása és a szervezetszintű munkamenet határozza meg. Minél elterjedtebb technológiákat, hatékonyabb eszközöket, képzettebb embereket alkalmazunk egy jól szervezett munkamenetben, annál hatékonyabban és alacsonyabb költséggel állíthatunk elő minőségi szoftvereket. A gyakorlatok során a hallgatók a Rational Unified Process (Jacobson et al., 1999.) szoftverfejlesztési módszertannal ismerkednek meg közelebbről, amely módszertan folyamatosan alkalmazkodik a jelentős technológiai változásokhoz és jól kialakított eszközöket biztosít a szoftverfejlesztési folyamat megfelelő támogatásához. 2.1 Rational Unified Process (RUP) Ez a szoftverfejlesztési módszertan kezdetben az Egységesített Eljárás (Unified Process) nevet viselte, amely módszertan a megalkotásakor (1990-es évek második fele) legnépszerűbb szoftvertervezési és -fejlesztési eljárásokat egyesítette és egységes jelölésmódot (UML) vezetett be a szoftver tervezése során. Ezt a módszertant a Rational (ma IBM) cég alkalmazta először, mint saját szoftverfejlesztési módszertant (a módszer megalkotói a Rational cég alkalmazottai voltak), ezért inkább a Rational Unified Process elnevezése terjedt el. 2

3 A módszertan egy iteratív és inkrementális eljárást definiál, amelynek során a megrendelő által megfogalmazott igények alapján elkészül a szoftver terve, majd e terv alapján valósítja meg a fejlesztő csoport a megrendelt szoftvert. A tervezés során a módszer végig szem előtt tartja a megrendelő igényeit (az azokat megfogalmazó használati eseteket) és a rendszer szerkezetében fennálló kapcsolatokat. Ezáltal az elkészült terv egyaránt könnyen értelmezhető a leendő felhasználók és az implementációt végző fejlesztői csoport tagjai számára is. A RUP módszertana fejlesztési folyamatot fázisokra osztja fel úgymint: előkészítés, kidolgozás, építés és átadás. Minden egyes fázis meghatározott munkamenetekből (követelmények meghatározása, analízis, tervezés, megvalósítás és tesztelés) álló ismétlések sorozatával jellemezhető (1. ábra). 1. ábra A RUP felépítése Az előkészítés fázis során a követelmény-feltárásra kell helyezni a hangsúlyt, azaz a megrendelő igényeit kell összefoglalni, amely alapján meghatározhatók a szoftverprojekt megvalósíthatósága, költségei, a tartandó határidők és a figyelembeveendő kockázatok. Ezután, kidolgozás során a felhasználói igényeket kell egy szerkezeti tervvé transzformálni, amely terv alapján a fejlesztők elvégezhetik a szoftver implementálását az építés fázisban. Végül, az átadás fázisban az elkészült szoftvert kell a végleges működési környezetbe helyezni és a leendő felhasználókat megtanítani annak használatára. 2. ábra A RUP és a projektmenedzsment 3

4 A tervezési és fejlesztési feladatokon kívül a szoftverprojekt hatékonyságát számos egyéb munkamenet befolyásolhatja. Ilyenek például az üzleti folyamatok modellezése, a projekt- és csapatmunka-koordináció, a fejlesztés közbeni konfiguráció- és verziókezelés és a környezet változásának kezelése. A RUP módszertana ezen folyamatokat is figyelembe veszi (2. ábra) a résztvevők feladatainak meghatározásakor. 3. Szoftvertechnológia gyakorlat A szoftvertechnológia gyakorlati oktatásához elméleti és gyakorlati programozási ismeretekre és a szoftvertechnológia elméletének alapos ismeretére van szükség (Sipos et al., 2005). Ennek megfelelően a tárgy előfeltételei között a Szoftver tervezés és technológia című előadás és a programozási készséget oktató tárgyak közvetlenül és közvetve szerepelnek. A gyakorlatok heti 2 órás laboratóriumi órák formájában kerülnek megtartásra, félévenként átlagosan héten keresztül. Az alacsony óraszám következtében csak egy módszertan alapjainak átfogóbb bemutatására és gyakorlására van idő a félévben. A választott szoftverfejlesztési módszertan az előző szakaszban ismertetett Rational Unified Process lett jól alkalmazhatósága és ipari elterjedtsége miatt. 3.1 Gyakorlatok a korábbi félévekben Mivel a számítógépes laborok kapacitása 24 fő, így az egyes gyakorlatok létszámkorlátja is 24 fő lett. Az első órán a hallgatók 4-5 fős csoportokba szerveződnek, csoportvezetőt választanak, meghatározzák a csapat többi tagjának a feladatát és egy általános feladatmegfogalmazás megismerése után specifikálják a csoport feladatát. Így elmondható az, hogy minden csoport azonos komplexitású, mégis egyedi feladatot old meg. A félév folyamán a RUP előkészítés és kidolgozás fázisának gyakorlati megismerése a cél. A hallgatók az UML 2.0 (Rumbaugh et al., 2005) diagramjait felhasználva elkészítik az általuk specifikált feladat megoldására készítendő szoftverrendszer tervét. Az első fázisban (előkészítés) a csoportok az általuk kijelölt feladat részletes követelményelemzését végzik el, amelyet használati eset diagramokban foglalnak össze, majd megkezdik a szoftver szerkezeti elemeinek és az elemek kapcsolatainak meghatározását, amelyek a tervben osztálydiagramok formájában jelennek meg. Ezt a fázist egy interfészprototípus készítésével zárják a csoportok. Az ezt követő második fázis (kidolgozás) a követelmények és a szerkezeti terv finomítását foglalja magában. A csoportok újra áttekintik a követelményeket, amelyeket a prototípus segítségével már egy alaposabb elemzésnek vethetnek alá. Az osztálydiagramokat pedig kiegészítik az osztályok elemeivel (adattagok és műveletek), és a diagramokon feltüntetett kapcsolatokat egészítik ki újabbakkal. A félév folyamán az egyes tervezési lépésekhez a gyakorlatot vezető oktató egy labdarúgó bajnokság menedzselését támogató alkalmazás készítéséről szóló esettanulmány (mintaterv és prototípus) segítségével ad útmutatót. A csoportmunka számonkérése három lépésben történik: az egyes fázisok végeztével a csoportok a terv pillanatnyi állapotáról készítenek dokumentációt és adják be azt a gyakorlatot vezető oktatónak véleményezésre, majd a félév végén a csoport egyik tagjának a többiek előtt kell bemutatnia a féléves munkájukat. 4

5 A csoportok munkájának értékelésekor a csoport vezetője kap az oktatótól osztályzatot, és a csoport többi tagjának munkáját neki kell értékelni úgy, hogy a kiosztott jegyek átlaga ne legyen nagyobb az ő jegyénél. A tapasztalat azt mutatja, hogy a csoportvezetők a jegyek kiosztásakor elsősorban azt veszik figyelembe, hogy a csoport tagjai megfelelő félévi érdemjegyet szerezhessenek (nagyon ritkán fordult elő elégségesnél rosszabb érdemjegy). A csoportmunka mellett a hallgatóknak a félév folyamán két zárthelyin is meg kell felelniük, amely dolgozatok a tanórákon megismert CASE-eszköz (Rational XDE Developer for Java) használatában való jártasságot és az UML-modellezési készséget mérik. A dolgozatokra elsődlegesen azért van szükség, mert segítségükkel elkerülhető, hogy a csoportmunkából kimaradó hallgatók is felmutassanak valamilyen eredményt a félév folyamán. Ezzel elkerülhető, hogy egy tervezési munkát nem végző hallgató a csoport vezetőjének jóindulatát kihasználva félévi jegyet szerezhessen. A hallgatók félévi osztályzata a csoportmunkára kapott érdemjegy és a két zárthelyi dolgozat eredményének számtani közepe lesz. Az 1. táblázat összefoglalja az elmúlt három tanév folyamán kiosztott érdemjegyek átlagait. Tanév 1. táblázat A korábbi félévek eredményei 1. zárthelyi dolgozat 2. zárthelyi dolgozat Csoportmunka Félévi jegy tanév 4,03 3,05 3,17 3, tanév 3,6 3,18 4,12 3, tanév 3,77 3,95 4,09 4,13 A korábbi félévek eredményei nem nevezhetők rossznak. Elmondhatjuk, hogy a hallgatók megértették a tárgy anyagát, mégis több fenntartás maradt bennünk azzal kapcsolatban, hogy az iskolából kikerülve is magabiztosan fogják alkalmazni az itt megtanult ismereteiket. E kétség elsődlegesen a leadott szoftver-tervek minőségéből fakad, amelyeken látszott, hogy a tervezési folyamat során a csoportokra nem nehezült a megvalósítás kényszere, és ennek következtében főként olyan terveket láthattunk a korábbi tanévek folyamán, amelyek minél nagyobb, komplexebb és látványosabb szoftvereket írtak le, ezzel próbálván lenyűgözni a gyakorlatot vezető oktatót a jobb jegy szerzés érdekében. Sajnos a tárgy tematikájából és követelményrendszeréből kifolyólag az oktató egy látványos és komplex rendszer alapos tervérét kénytelen volt pozitívan értékelni függetlenül attól, hogy a szoftver megvalósítása akár éveket is igénybe vehet. Főként a tervezett rendszerek méretének korlátok közé szorítása érdekében és a gyakorlatok alatt megszerzett ismeretek kibővítése miatt döntöttünk a Szoftvertechnológia tárgy tematikájának a tervezett szoftverrendszer implementálásával való kibővítése mellett, amely módosítás a tematika és a követelményrendszer újrafogalmazásához vezetett. 3.2 Gyakorlatok most A gyakorlatok átalakításánál arra törekedtünk, hogy a korábbi tematikából és követelmények közül a lehető legtöbb jó elemet tartsunk meg úgy, hogy minél több hátrányos tulajdonságától megszabadítsuk az órákat. A legnagyobb hátránynak a szoftver implementálásának hiányát tartottuk, ezért a féléves tematikát úgy módosítottuk, hogy abban jusson idő a tervezett program megvalósítására is. Így a félév során a hallgatói csoportok az előkészítés és kidolgozás fázisok mellett a RUP 5

6 építés fázisával is megismerkedhetnek. Ehhez a változtatáshoz a hajtóerőt a korábbi félévekben a programozási ismereteket oktatott tárgyak alapvető megváltoztatása adta, amely változások következtében a hallgatók egységes és jól alkalmazható ismereteket szereznek a C# programozási nyelvről. Ezekre az ismeretekre nyugodt szívvel alapozhattunk a szoftvertechnológia gyakorlat komplex szoftverrendszerének tervezése és megvalósítása során. A félév időbeosztása a korábbi 6+6 hétről hétre változott, azaz az egyes fázisokra kevesebb idő jut. Tapasztalataink szerint ez nem okozott problémát a hallgatóknak: minden feladatot határidőre teljesítettek. Ez a változtatás eleget tett a várakozásainknak: az ebben a félévben leadott tervek sokkal átgondoltabbak és lényeglátóbbak lettek a korábbiaknál. Egyedüli problémát a tervek és az elkészült szoftverprototípus közötti konzisztencia fenntartása jelentette. A második nagyobb tartalmi változást a gyakorlati foglalkozásokon mintaként használt esettanulmány lecserélése jelentette. A meglévővel az volt a probléma, hogy bár explicit nem szerepelt a tervben, de egy web-alapú alkalmazás terve volt, amely igen gyakran tévútra terelte a csoportokat. Helyette egy képzeletbeli bankfiók ügyvitelét támogató kliensszerver alkalmazás tervét és prototípusát használjuk a RUP folyamatának bemutatására. A harmadik jelentős változtatás a követelmények módosítása volt. A korábbi zárthelyi dolgozatokat váltotta most fel a szoftverprototípus elkészítésének feladata. A csoportok most minden fázis végén leadnak egy dokumentációt a tervek pillanatnyi állapotáról, amelyhez az építés fázis végeztével a szoftver prototípusát is mellékelik. Bár ezzel a változtatással megnyitottunk egy kiskaput, amelyen keresztül a munkából kimaradó hallgatók is félévi jegyhez juthatnak. Ennek ellenére az elmúlt félév tapasztalatai alapján kijelenthetjük, hogy a csoportok valamennyi tagja aktívan részt vett a félévi munkában. A fenti változtatásoknak nem várt mellékhatásai is jelentkeztek, amelyek közül a legszembetűnőbb a munka végeztével megtartott bemutató előadások a korábbi félévekhez képest jelentkező minőségi javulása volt. Ez feltehetőleg az elkészült szoftver prototípusnak köszönhető, ami az előadást tartó hallgatónak szemléltető eszközt nyújt a féléves munka és annak eredményének bemutatására. 4. Összegzés Összességében elmondhatjuk, hogy a Szoftvertechnológia gyakorlat című tárgy tematikájának és követelményrendszerének megváltoztatásával sikerült egy olyan tárgyat létrehoznunk, amely a diploma megszerzése után is jól használható ismereteket ad és a tárgy teljesítése sem jelent a korábbiakhoz képest nagyobb terhet a hallgatóknak. Ezt jól személteti a 2. ábra, amely az elmúlt négy év folyamán a félévi jegyek alakulását mutatja. Azáltal, hogy a hallgatók a szoftverfejlesztés folyamatából nem csak a tervezést, hanem a prototípuskészítést is megismerik, sokkal átfogóbb képet kapnak egy valóságos szoftverprojekt menetéről. Bár a cikkünk nem emeli ki, de a félév folyamán igyekeztünk a csoportmunka szervezési részét is kihangsúlyozni, hogy a feladat megvalósítása minél életszerűbb körülmények között történhessen. Az oktatói és hallgatói visszajelzések is azt mutatják, hogy a szoftverfejlesztési módszerek oktatása az új struktúrájú gyakorlatok által hatékonyabbá vált. 6

7 Elképzeléseink szerint a tárgy fejlesztésével nem állunk meg ezen a ponton. A továbbiakban az oktatás eszközeinek elsősorban a felhasznált CASE-eszköznek a felülvizsgálatát és esetlegesen jobbra cserélését fogjuk megtenni. 2. ábra A félévi jegyek alakulása az elmúlt 4 évben A tantárgy időbeosztása, követelményrendszere, az oktatási és segédanyagok elérhetők az alábbi weboldalon: Irodalomjegyzék [1] Ivar Jacobson, Grady Booch, James Rumbaugh (1999) The Unified Software Development Process. Addison Wesley Longman Inc., Reading, Massachusetts [2] James Rumbaugh, Ivar Jacobson, Grady Booch (2005) The Unified Modeling Language Reference Manual, Addison Wesley Longman Inc., Reading, Massachusetts [3] Sipos Marianna, Tick József, Katona Krisztina, Kurdi Zsombor (2005) A szoftverfejlesztés mint mérnöki munka, Informatika a felsőoktatásban konferencia, Debrecen, ISBN: