DOKTORI (PHD) ÉRTEKEZÉS

SDP keretrendszer a szoftverminták használatát befolyásoló tényezők alapján

DOKTORI (PHD) ÉRTEKEZÉS Angster Erzsébet Budapest, 2006

Témavezető: Dr. Vámos Tibor akadémikus

Eötvös Loránd Tudományegyetem Informatika doktori iskola Az informatika alapjai és módszertana doktori program Iskola- és programvezető: Dr. Demetrovics János akadémikus

Angster Erzsébet: Doktori (PHD) értekezés, 2006

ii

1. A dolgozat felépítése, az SDP definíciója

Tartalomjegyzék Magyar nyelvű összefoglaló Angol nyelvű összefoglaló 1. A dolgozat felépítése, az SDP definíciója......................................................................... 1 1.1. A dolgozat felépítése ............................................................................................... 1 1.2. SDP – definíció........................................................................................................ 1 2. A szoftverminták és kialakulásuk ..................................................................................... 3 2.1. Szoftverkrízis........................................................................................................... 3 2.2. Újrahasználás........................................................................................................... 5 2.3. A szoftverminták története ...................................................................................... 7 2.4. Minta (pattern) ......................................................................................................... 8 2.5. A szoftverminták ismérvei..................................................................................... 11 2.6. Mintasablonok ....................................................................................................... 13 2.7. Minta szakterületek................................................................................................ 16 2.8. A minta absztrakciós szintjei................................................................................. 16 2.9. A mintacsomag teljessége...................................................................................... 17 2.10. Implementációs minták.......................................................................................... 19 2.11. Tervezési minták.................................................................................................... 19 2.12. Architekturális minták ........................................................................................... 21 2.13. Elemzési minták .................................................................................................... 22 2.14. GRASP minták ...................................................................................................... 22 2.15. Pedagógiai minták ................................................................................................. 23 2.16. Mintakonferenciák, mintakészítés, pásztorkodás .................................................. 25 2.17. A minták használatának fontossága....................................................................... 26 3. A kutatás folyamata, első eredmények............................................................................ 29 3.1. A kutatás folyamata ............................................................................................... 29 3.2. Szoftverfejlesztés – kísérleti tantárgy.................................................................... 30 3.3. Interjúk................................................................................................................... 30 3.4. Abakusz szoftverfejlesztő verseny......................................................................... 32 3.5. Nemzetközi workshop a szoftverfejlesztés tanításáról .......................................... 32 3.6. Az „Ördögi kör” felfedezése (1. tézis) .................................................................. 33 3.7. A mintahasználattal kapcsolatos hipotézisek ........................................................ 34 4. Felhasznált kutatások ...................................................................................................... 35 4.1. Az innováció terjedése........................................................................................... 35 4.2. Egész termék.......................................................................................................... 37 4.3. Szoftverfejlesztési innováció ................................................................................. 38 4.4. A fejlesztő bevonása és irányításérzékelése .......................................................... 40 4.5. A minták terjedését befolyásoló tényezők vizsgálata ............................................ 42 5. A mintahasználatot befolyásoló tényezők....................................................................... 45 5.1. A mintahasználatot befolyásoló tényezők modellje (2. tézis) ............................... 45 5.2. Az egyes tényezők bemutatása .............................................................................. 47 5.3. Mintahasználat....................................................................................................... 47 i

Angster Erzsébet: Doktori (PHD) értekezés, 2006

6. 7.

8.

9.

10.

11.

12.

5.4. A mintahasználat terjedési környezete...................................................................48 5.5. A mintahasználat érzékelt tulajdonságai................................................................57 5.6. A mintahasználat érzékelt hatásai ..........................................................................61 A felmérés........................................................................................................................63 6.1. A kérdőív................................................................................................................63 6.2. Az adatgyűjtés módja .............................................................................................65 A kérdőívek részletes elemzése és értékelése..................................................................67 7.1. A kitöltő személyes adatai .....................................................................................67 7.2. Vélemények a kérdőívről (92–93. kérdés) .............................................................69 7.3. Szoftverminta használat (12–18. kérdés) ...............................................................71 7.4. A mintahasználatot befolyásoló tényezők (19–68. kérdés)....................................75 7.5. SDP-city iránti igény (69-76. kérdés).....................................................................84 A kérdőívek összefoglaló értékelése ...............................................................................89 8.1. Vélemény a kérdőívről ...........................................................................................91 8.2. Szoftverminta használat (H1–H4)..........................................................................91 8.3. A mintahasználat terjedési környezete (B1–B12) ..................................................92 8.4. A mintahasználat érzékelt tulajdonságai (B13–B18) .............................................92 8.5. A mintahasználat érzékelt hatásai (B19–B20) .......................................................93 8.6. SDP-city iránti igény..............................................................................................93 A mintahasználattal kapcsolatos tézisek..........................................................................95 9.1. Nem használják a mintákat (3. tézis) .....................................................................95 9.2. Az eredmények összevetése más kutatásokkal ......................................................95 9.3. Alacsonyak a mintahasználatot pozitívan befolyásoló tényezők értékei (4. tézis)................................................................................................................101 9.4. Nincs fórum, SDP-tárház és tananyag (5. tézis)...................................................102 Innovációs modell: SDP keretrendszer..........................................................................103 10.1. Az SDP keretrendszer felállítása (6. tézis)...........................................................103 10.2. A mintahasználatot befolyásoló tényezők az SDP keretrendszerben...................104 10.3. A mintahasználat terjedési környezetének tulajdonságai az SDP keretrendszerben ..................................................................................................105 10.4. A mintahasználat érzékelt tulajdonságai az SDP keretrendszerben....................107 10.5. A mintahasználat érzékelt hatásai az SDP keretrendszerben ...............................108 10.6. Tervek, tervezett kutatások ..................................................................................109 Felmérés a mintahasználat hasznosságának bemutatására ............................................111 11.1. A feladat – szakterületi modell készítése .............................................................112 11.2. Megoldás – 1. verzió ............................................................................................115 11.3. Felhasznált minták Fowler elemzési mintáiból....................................................117 11.4. Megoldás – 2. verzió ............................................................................................120 11.5. A beadott munkák elemzése.................................................................................121 11.6. Egy konkrét beadott munka..................................................................................124 11.7. Vélemények..........................................................................................................128 11.8. Eredmény, konklúzió ...........................................................................................130 11.9. A mintahasználat hasznossága (7. tézis) ..............................................................130 Hivatkozásjegyzék.........................................................................................................131

Melléklet – Az internetes felmérés kérdőíve ........................................................................137

ii

1. A dolgozat felépítése, az SDP definíciója

Magyar nyelvű összefoglaló

A szoftverminta egy adott szoftverfejlesztési környezetben gyakran előforduló probléma általános és jól dokumentált megoldása, melyet már több ember, több alkalommal kipróbált, és amely a legjobb gyakorlatnak bizonyult. A szoftverfejlesztő társadalom egyetért abban, hogy a szoftverfejlesztés minősége nem kielégítő, valamint abban, hogy a szoftvermintahasználat a hatékony fejlesztés elengedhetetlen feltétele. A szoftverminták használata azonban nem terjed – a magyar szoftverfejlesztői közösség nagy része nincs tisztában a minta fogalmával. A kutatás célja annak megállapítása, hogy a szoftverfejlesztői körökben terjed-e a mintahasználat; ha nem terjed, akkor miért nem; végül mit kellene tenni annak érdekében, hogy terjedjen. Felfedeztem a szoftverfejlesztés ördögi körét, és rámutattam, hogy az ördögi körből való kijutás egyik feltétele, hogy az oktatók és tanulók könnyen hozzájuthassanak szoftvermintákból építkező, mintaszerű SDP1-khez [Angster, 2004c]. Feltérképeztem a szoftverfejlesztési innováció, illetve a mintahasználat terjedésével kapcsolatos kutatásokat (Az innováció terjedése, Egész termék, Szoftverfejlesztési innováció, A fejlesztő bevonása és irányításérzékelése, A minták terjedését befolyásoló tényezők vizsgálata), s ezek alapján felállítottam a mintahasználatot befolyásoló tényezők modelljét. A modell tényezői például: mintatárház, SDP-tárház, oktatás, véleményvezető (aki pozitívan befolyásolja a többi fejlesztőt), láthatóság (a potenciális használó látja a másikat, hogy mintákat használ) stb.

1

Az SDP (Software Development Pack, szoftverfejlesztési csomag) egy számítógépen megoldandó feladat, és annak működő, dokumentált megoldása. Az SDP minden kelléket tartalmaz, amely szükséges a szoftver használatához és újrahasználatához. Az SDP kötelezően tartalmazza a következőket: Vízió, Fejlesztői dokumentáció, Felhasználói dokumentáció, Forráskód (kommentezett), Futtatható kód (telepítési csomag, tesztadatok) ... [Angster, 2004c]

iii

Angster Erzsébet: Doktori (PHD) értekezés, 2006 Széleskörű internetes felmérést készítettem Magyarországon arról, hogy a szoftverfejlesztői körök (fejlesztők, oktatók, tanulók és menedzserek) használnak-e mintákat, és hogy a mintahasználatot más szerzők szerint pozitívan befolyásoló tényezők milyen mértékben vannak jelen. Bebizonyítottam, hogy Magyarországon a szoftverfejlesztői körök − nem használnak szoftvermintákat; − alacsonyak a mintahasználatot más szerzők szerint pozitívan befolyásoló tényezők értékei; valamint − nincs fórum, SDP-tárház és tananyag, amelyek feltehetően szintén pozitívan befolyásolnák a mintahasználatot. Ezen állításokat az Abakusz szoftverfejlesztési verseny elemzésével és egy tantermi kísérlettel is alátámasztottam. Kidolgoztam az SDP keretrendszer újítási modellt, melynek elsődleges célja a mintahasználat terjedésének elősegítése, s ezzel a szoftverfejlesztés minőségének javítása. Az SDP keretrendszer tulajdonságait a felmérés eredményének megfelelően alakítottam ki, vagyis jelen vannak a mintahasználatot pozitívan befolyásoló tényezők: mintatárház, SDP-tárház stb. Az SDP keretrendszer törekszik arra, hogy tárházában minél több minőségi alkotás szerepeljen, ezért az alkotásokat szakemberek segítik és minősítik. Minden alkotó kap egy pásztort, aki az alkotót addig „terelgeti”, amíg az alkotás megfelelő, „pásztorolt” színvonalú nem lesz. A minőség szerint szűrt alkotások között sokkal hatékonyabb a keresés. Elindítottam az SDP keretrendszer egy konkrét megvalósítását, az SDP-city weblapot (http://sdp-city.hu). A weblap már részben működik, fejlesztésében vezető szerepet játszom. Elindítottam az SDP-city tartalommal való feltöltését: kialakítottam egy kezdeti szoftverminta tárházat, mely már alapja lehet az SDP-k elkészítésének. Elkészítem, illetve elkészíttetem az első SDP-ket; kialakítom a zsűrit, és pásztorokat szervezek be. Az SDP-city alkotásai nyílt forráskódúak és nyílt dokumentációjúak lesznek. A munka folyamatban van. Végül készítettem egy felmérést a mintahasználat hasznosságáról oktatók, fejlesztők és hallgatók egy szűk körében. Ebben kiderült, hogy a szoftverminta használata segít a fejlesztésben, de a minták helyes alkalmazásához nagyfokú kreativitásra van szükség.

iv

1. A dolgozat felépítése, az SDP definíciója

Angol nyelvű összefoglaló

A software pattern is a general and documented solution of a frequently occurred problem, in a given software environment, which was tried out by more than one people, more than one times and which proved to be the best practice. The software developer's community agrees that the quality of software development is not satisfactory, and that the use of software patterns is an indispensable condition of efficient development. However, the use of software patterns does not spread – the concept of software pattern is not clear for the majority of the Hungarian software development community. The purpose of this research is to establish, whether the use of software patterns spreads or not; if not, why; and what to do for the sake of spreading. I discovered the software development's vicious circle, and pointed out: to overcome the vicious circle, the first condition is that trainers and students can easily access exemplary SDP2s, built from software patterns. I mapped the software development innovation and pattern use researches (Diffusion of Innovation, Whole Product, Software Development Innovation, Involvement and Perceived Control of Software Developers, Factors Affecting the Diffusion of Software Patterns), and set up the model of factors affecting the pattern use. The factors are for example: Pattern repository, SDP repository, training, opinion leader (who positively affects other developers), visibility (the potential user sees the other one using patterns) etc. I made a wide-ranging survey in Hungary, whether the software developer's community (developers, trainers, students and managers) use patterns or not; and to what extent are the factors present, which positively affect the pattern use according to others.

2

The SDP (Software Development Pack) is a task to solve on a computer with working and documented solutions. An SDP has all components necessary for using and reusing software. An SDP contains: Vision, Technical documentation, User’s guide, Source code, Running code (deployment pack, test data)... [Angster, 2004c]

v

Angster Erzsébet: Doktori (PHD) értekezés, 2006 I have proved, that the software developers community in Hungary − does not use software patterns; − values of factors – positively affecting pattern use according to other authors – are low; and − there are no forum, SDP repository, and teaching material, which presumably also positively affected the pattern use. I supported these statements by analyzing the "Abakusz" Software Development Competition, and an experiment in classroom. I worked out the SDP framework innovation model; its primary goal is to help the diffusion of pattern use, and with this, to improve the quality of software development. I formed the features of the SDP framework according to the survey's result, that is, the factors, positively affecting the pattern use – as Pattern repository, SDP repository etc., – are present. The SDP framework aims the works being quality works, therefore experts will help and qualify the developers. Every developer gets a "shepherd", who shepherds the developer as long as the work will be on "shepherded" level. It is much more effective to search works, if they are filtered by quality. I made a concrete implementation of the SDP framework, namely the SDP-city (http://sdp-city.hu). This web page partly works already, I lead its development. I started filling up the SDP-city with contents: I formed an initial software pattern repository, which could be the base of developing SDPs. I develop or make develop the first SDPs; I establish the jury and get shepherds. The works in the SDP-city will be open source and open documentation. The work is in progress. Finally, I made a survey about the usefulness of pattern use with some trainers, developers, and students. It turned out, that the use of software patterns helps in development, but applying the patterns in a right way needs a lot of creativity.

vi

1. A dolgozat felépítése, az SDP definíciója

1.

A dolgozat felépítése, az SDP definíciója

1.1.

A dolgozat felépítése

A 2. fejezet egy szakmai áttekintést ad a szoftvermintákról, kiemelve azokat a lényeges pontokat, amelyeket az SDP-city keretrendszer, mint újítási modell felhasznál. A 3. fejezet bemutatja a kutatás folyamatát, fontosabb lépéseit: lényegében ezek a lépések kerülnek kifejtésre a dolgozat további részeiben. A 4. fejezet tartalmazza a kutatás előzményeit; a megelőző felméréseket és az ezek alapján felállított hipotéziseket. Az 5. fejezet összefoglalja a jelen kutatásban felhasznált legfontosabb más kutatásokat. A 6. fejezet bemutatja a szoftverminták használatáról szóló felmérés alapjául szolgáló kutatási modellt: a felmérésben résztvevő, a mintahasználatot feltételezhetően befolyásoló tényezőket és azok egymásra hatásait. A 7. fejezet részletesen bemutatja az egyes tényezőket. A kérdőívek kiértékelése a 9. és a 10 fejezetekben találhatók, majd ezt követik a felállított tézisek a 11. fejezetben. A 12. fejezet bemutatja az SDP-keretrendszert mint innovációs modellt, amelyeket a tézisek alapján állítottam fel. Végül a 13. fejezet egy felmérésen keresztül próbálja érzékeltetni a szoftverminta-használatot: a vizsgálatban résztvevők egy konkrét feladat szakterületi modelljét készítették el a megadott szakterületi minták alapján. Sok idézetnek csak a magyar fordítását közlöm. Az egységes nyelvi stílus érdekében a lefordított idézetek is idézőjelek között vannak, ezek alapértelmezésben az én fordításaim.

1.2.

SDP – definíció

Az SDP fogalma az értekezés kulcsfontosságú eleme, definíciója a következő [Angster, 2004c]: Az SDP (Software Development Pack, szoftverfejlesztési csomag) egy számítógépen megoldandó feladat, és annak működő, dokumentált megoldása. Az SDP minden kelléket 1

Angster Erzsébet: Doktori (PHD) értekezés, 2006 tartalmaz, amely szükséges a szoftver használatához és újrahasználatához. Az SDP kötelezően tartalmazza a következőket: − Vízió (a feladat rövid leírása) − Fejlesztői dokumentáció (követelmények, architektúra dokumentáció, tervezési modell, implementációs modell stb.) − Felhasználói dokumentáció − Forráskód (kommentezett) − Futtatható kód (telepítési csomag, tesztadatok ...) További, nem kötelező elemek: − A fejlesztés segédállományai (pl. CASE modellek, projektfájlok) − A konkrét fejlesztés története (sorrend, mérföldkövek, megelőző dokumentumok, sikerek, tévutak, tanulságok) − A csomag megértését segítő oktatóanyagok A csomag lehet egy teljes alkalmazás vagy egy általános célú komponens. Ez utóbbi esetben a komponens bemutatására egy tesztalkalmazást kell készíteni.

2

2. A szoftverminták és kialakulásuk

2.

A szoftverminták és kialakulásuk A szoftverminták a szoftver újrahasználás egy formája. Ebben a fejezetben bemutatom a

szoftverminták kialakulásának szakmai hátterét, majd ismertetem a szoftverminta fogalmát, a minták szakterületeit, absztrakciós szintjeit, végül bemutatok néhány további – a mintákkal kapcsolatos – alapvető tudnivalót.

2.1.

Szoftverkrízis „A legtöbb szoftverfejlesztés egy „code and fix” alapú, kaotikus folyamat.” Fowler [2003b]

A szoftverfejlesztés nehéz „vállalkozás”. Egyre nagyobbak a felhasználói igények, a készítendő szoftverek pedig egyre bonyolultabbak. Általános probléma, hogy a szoftverek minősége nem kielégítő. A nagy projektek jelentős százaléka sikertelen, illetve a szoftverek elkészülte után a kívánatosnál több a reklamáció. A pillanatnyi teljesítési elvárások miatt a szoftverfejlesztőknek nincs idejük tervezni, illetve dokumentálni. A problémát nehezíti, hogy a meglévő szoftverfejlesztési módszertanok meglehetősen bonyolultak, nincsenek teljes és konkrét, jól tervezett és dokumentált szoftverpéldák. 1994 szeptemberében a Scientific American egyik kiemelt (címlapon szereplő) cikke a Software's Chronic Crisis volt [Gibbs, 1994]. Gibbs a következőket írja: 50 év fejlődés ellenére a szoftveripar évekkel, talán évtizedekkel van elmaradva a fejlesztési alapelvekben ahhoz, hogy megfeleljen az információs társadalom elvárásainak. Példaként hozza fel a Denver-i nemzetközi repülőtér tervezett „csodarendszerének” látványos bukását. Gibbs a legnagyobb problémát a szoftverfejlesztők szaktudásában és a minőségi oktatás hiányában látja. A cikk egy interjút készített Brad J. Cox-szal, aki így nyilatkozik: „If we are ever going to lick

3

Angster Erzsébet: Doktori (PHD) értekezés, 2006 this software crisis, we're going to have to stop this hand-to-mouth, every-programmer-buildseverything-from-the-ground-up, preindustrial approach.”3 [Gibbs, 1994, pp. 86] A cikk írója szerint Barry W. Boehm fontosnak tartja, hogy a szoftverfejlesztők hivatalos vizsgát tegyenek, ahogyan a műszaki tudományok egyéb területein ez elvárt. Bár – teszi hozzá – a hivatalos vizsga csak akkor számít, ha a fejlesztőket helyesen oktatjuk. Pillanatnyilag olyan alapvető dolgokat nem tanítanak még az egyetemeken sem, mint felhasználói dokumentációkészítés vagy szoftverkarbantartás. A Design Patterns [Gamma et al., 1995] bevezetője így kezdődik: „Designing objectoriented software is hard, and designing reusable object-oriented software is even harder.”4 A Byte Magazinban jelent meg Bruce F. Webster [1996] cikke: The Real Software Crisis. Webster szerint a szoftverkrízis sarokpontja a minőségi szoftverfejlesztők hiánya. Szerinte a zenészekhez és művészekhez hasonlóan a kiemelkedő szoftverfejlesztők születnek, azokat nem lehet kiművelni – a népességnek csak egy igen kis százaléka lesz és lehet igazi szoftverfejlesztő. Webster az „És mi van a jobb iskolákkal?...”, kérdésre azt válaszolta, hogy az nagyon fontos, mert emeli a fejlesztők színvonalát, azonban az alapvető problémát nem oldja meg. Jelen értekezlet szerzője vitatkozik ezzel az éles kijelentéssel – szerinte a szoftverfejlesztés nagy része nem művészet, hanem szakmunka, a jó oktatással pedig jó szakembereket lehet nevelni. A következő idézet Tyson Gill [2000] Planning Smarter című könyvének híres 2. fejezetéből való (Chapter 2 – Understanding the Planning Process): „Objektív statisztikák, saját minősítések, ügyfelek reakciói és anekdoták mind megerősítik, hogy a meghiúsult szoftverfejlesztési projektek aránya kínosan magas. A 80-90%-os sikertelenségi arányra rendszeresen hivatkoznak, melyet a közvélemény el is fogad. Az érték pontossága természetesen függ attól, hogyan mérjük a sikert és a kudarcot, de bárhogyan is történjék a mérés, a helyzet nem jó. A szoftverfejlesztési eljárások javítása rendkívül fontos.” Az Open Source közösség alapcikkében, a The Cathedral and the Bazaar-ban Raymond [1998] ezt mondja: „... nagyon ritka az olyan irányított projekt, amely eléri a megbízható

3 4

Ha túl akarunk jutni a szoftverkrízisen, akkor megálljt kell parancsolnunk ennek a máról holnapra élő, „minden programozó mindent az elejéről felépítő”, iparosítás előtti megközelítésnek. Megtervezni egy objektumorientált szoftvert nehéz, de megtervezni egy újrahasználható objektumorientált szoftvert még nehezebb.

4

2. A szoftverminták és kialakulásuk programműködést határidőre, belefér a költségvetésébe, és minden, az előírásnak megfelelő funkciót tartalmaz, sőt az is ritkaság, hogy ezekből egyetlen feltétel teljesül. (Karsai Róbert fordítása)” Pressman [2000] szerint egy információs rendszerekkel foglalkozó cég 1990-ben a teljes költségvetés 60%-át költötte karbantartásra, 2000-ben már a 80%-át. Fowler [2003b] azt állítja, hogy a legtöbb szoftverfejlesztés egy „code and fix” alapú, kaotikus folyamat. A szoftver-rendszereket tervezés nélkül, rövidtávú döntések alapján rakosgatják össze. Kis rendszerek esetén ez még működik is, de ahogy a rendszer nő, az új funkciók hozzáadása nagyon bonyolulttá válik, a hibákat pedig rendkívül nehéz kiszűrni. Mindezek lehetetlenné teszik a határidők betartását. Longstreet [2003] szerint a projektek egyre nagyobbak, bonyolultabbak és drágábbak, és ez a tendencia a következő évezredben folytatódni fog. A felhasználók étvágya még mindig nagyobb, mint amit az IT (Information Technology) cégek képesek kielégíteni. A legtöbb IT szakember felismeri e tényt, ámde komolyabb erőfeszítéseket nem tesz.

2.2.

Újrahasználás „Good programmers know what to write. Great ones know what to rewrite (and reuse).”5 [Raymond, 1998]

A „szoftverkrízist” az ipar a szoftver-újrahasználás támogatásával próbálja enyhíteni. Kész komponensek, már jól bevált megoldások beépítésével a végső termék várhatóan sokkal megbízhatóbb, karbantarthatóbb, az elkészítési idő pedig sokkal rövidebb. Ha az átlag szoftverfejlesztő szakembert megkérdezik, mi az objektumorienált technológia legfőbb előnye, a válasz szinte mindig az újrahasználás [Fowler, 1997]. Sajnos azonban az erőfeszítések eddig elsősorban a kód és a technikai megoldások újrahasználására irányultak, amelyek mellőzték a szoftverfejlesztési eljárás és az emberi dolgok aspektusait. A Hiperdictionary [2003] szerint például: „Az újrahasználás (reuse) egy alkalma-

5

„A jó programozók tudják, mit kell írni. Az igazán nagyok tudják, mit kell átírni (újrahasználni).”

5

Angster Erzsébet: Doktori (PHD) értekezés, 2006 záshoz kifejlesztett kód felhasználása egy másik alkalmazásban. Az újrahasználás általában programkönyvtárak használatával történik.” A kód-újrahasználás a szoftverfejlesztésben csak mérsékelt sikereket hozott. A szoftverminták készítése és használata egy újabb kísérlet az újrahasználható termékek fejlesztésére és csomagolására. Az újrahasználás egy termék (artefact), vagy érték (asset) sokszori felhasználásán alapuló újbóli felhasználása. A szoftverfejlesztés bármely terméke újrahasználható, beleértve a forráskódot, komponenst, tervet, használati esetet vagy dokumentációt. [Booch, 1994] Az újrahasználás elméletileg rengeteg problémára adhatna megoldást, a gyakorlatban azonban a cégek máig nem sokat profitáltak belőle. Az újrahasználható elemek implementálásában sok buktató rejtőzik, mint például annak a tudásnak a hiánya, mely a lehetőségek kihasználására irányul. [Jacobson et al., 1997] Karlsson [1995] szerint az újrahasználás két fő tevékenységre osztható: (1) az újrahasználatért történő tevékenység (for reuse); ide tartozik az értékfejlesztés és menedzselés; (2) újrahasználattal történő tevékenység (with reuse); ide tartozik a termékfejlesztés. Vannak rutin termékek, amelyek csak az „újszülöttnek újak”, és vannak innovatív termékek, amelyeket az adott feladat megoldásához egyedi esetként kell elkészíteni, megalkotni. Pillanatnyilag a legtöbb szoftverfejlesztő a rutin terméket is önállóan állítja elő, minduntalan „feltalálva a kereket”. A szoftver újrahasználás általában csak szervezeteken belül működik, szerződési és jogi problémák miatt. „Kié a jog egy fejlesztési projekt erőforrásainak újrahasználásához?” [Frakes et al. 1995] Egy szervezetben az újrahasználás nem történik magától, azt meg kell szervezni [Booch, 1994]. A fejlesztők oktatása és motiválása a vezetőség felelőssége. Az újrahasználás nem csak egyszerűen azért fordul elő, mert nem tudunk megoldani egy problémát. A fejlesztők beteszik az anyagot a tárházba, mások pedig kiveszik onnan [Fafchamps, 1994]. Egy újrahasználási program akkor a leghatékonyabb, ha az újrahasználásért külön személyek felelősek [Booch, 1994]. Az újrahasználás pénzbe kerül. Az újrahasználás egy hosszú távon megtérülő befektetés. A mérleg egyik serpenyőjében van az újrahasználás potenciális előnye, a másikban pedig az idő

6

2. A szoftverminták és kialakulásuk és energia, amely szükséges az újrahasználható elemek azonosítására, adminisztrálására, és a nagyobb rendszerbe való integrálására. Az újrahasználás idő, az idő pedig be van határolva. Általában nincs arra idő, hogy az elkészített komponensekből újrahasználhatóakat készítsünk, és arra sincs idő, hogy más projektekben kutassunk használható komponensek után. [Coad et al., 1991] A kutatók abban általában megegyeznek, hogy a szoftver újrahasználásba való rövidtávú befektetés hosszú távon megtérül [Booch, 1994].

2.3.

A szoftverminták története

1977-ben Christopher Alexander, a University of California, Berkeley építész professzora A Pattern Language – Towns-Buildings-Construction című könyvében [Alexander et al., 1977] építészeti mintákat gyűjtött össze. A megadott minták mindegyike egy-egy építészeti probléma megfogalmazása és megoldása. A mintanyelv (pattern language) arra utal, hogy a minták az építészet szempontjából lényegében teljesek. A könyv részletes, gyakorlati leírásokat tartalmaz városok, szomszédságok, házak, kertek és szobák stb. tervezéséhez, építéséhez. Alexander elméleti könyve a The Timeless Way of Building [Alexander, 1979], mely a mintanyelv használatáról és tervezési útmutatásokról szól. A szoftverfejlesztők rájöttek, hogy a minták a szoftverfejlesztés területén is alkalmazhatók – remélve a még mindig tartó szoftverkrízis enyhítését. Minél bonyolultabb egy rendszer, a minták annál nagyobb segítséget nyújthatnak. Az 1980-as évek végefelé a fejlesztők elkezdtek mintákat gyártani. Elsőként Kent Beck és Ward Cunningham, a Smalltalk úttörői mutatják be Human computer interface mintáikat az 1987-es OOPSLA (Object-Oriented Programming, Systems, Languages and Applications) konferencián [Beck et al., 1987]. Az öt darab minta Smalltalk ablakok tervezésével kapcsolatos. A Smalltalk-ban került bevezetésre az egyik jelentős tervezési minta, az MVC (Model–View–Controller). A keretrendszer fejlődésével és népszerűvé válásával a tervezési minták kezdtek fontossá válni. Az 1991-es és 1992-es OOPSLA konferenciákon Bruce Anderson workshopot szervezett Towards an Architecture Handbook címmel. A négyek (Gang of Four)6: Gamma, Helm, Johnson és Vlissides ekkor találkoztak, és határozták el a tervezési minták összegyűjtését. 1992-ben

6

A könyv négy szerzője „Gang Of Four” (négyek bandája, rövidítve GOF) néven vált ismertté.

7

Angster Erzsébet: Doktori (PHD) értekezés, 2006 megjelenik Peter Coad cikke a Communications of the ACM-ben Object-oriented Patterns címmel [Coad, 1992]. Ebben Coad már tervezési és analízis mintákról ír. Szintén 1992-ben jelenik meg Jim Coplien könyve, melyben hasznos C++ idiómákat gyűjt össze [Coplien, 1992]. 1993-ban megalakul a Hillside group: a csoport mintákat gyárt, megbeszéléseket tart, és kitalálja a PLoP (Pattern Language of Program design) konferenciát. 1994-ben megtartják az első PLoP konferenciát. 1995-ben megjelenik a híres tervezési mintagyűjtemény, a Design Patterns – Elements of Reusable Object-Oriented Software7 [Gamma et al., 1995]. Még ebben az évben kiadásra kerül az első Pattern Languages of Program Design könyv [Coplien et al., 1995]. Ezután sorban szerveznek PLoP konferenciákat több földrészen is. Megjelennek a Pattern Languages of Program Design további kötetei [Vlissides et al., 1996; Martin et al., 1998; Harrison et al., 2000], és további mintákkal foglalkozó könyvek. A Hillside group a szoftverfejlesztés minőségének javítását tűzte ki célul; honlapjának címsorában ez áll: „A group dedicated to improving the quality of software development”8 [Hillside, 2003].

2.4.

Minta (pattern) „(The use of patterns) will have a profound and enduring effect on the way we write programs.”9 Ralph Johnson & Ward Cunningham, In [Coplien et al., 1995]

A mintának több definíciója is létezik. Fowler szerint a mintához kétségkívül nehéz közös definíciót találni [Fowler, 1997, pp. 5]. A szótárak szerint a minta meglehetősen konkrét; a szoftverközösség azonban megegyezik abban, hogy a minta egy adott probléma általános megoldása.

7 8 9

Tervezési minták – Újrahasználható objektumorientált szoftver-elemek Egy csoport, mely elkötelezte magát a szoftverfejlesztés minőségének javításában A minták használata mélyreható és tartós hatással lesz a programok írására.

8

2. A szoftverminták és kialakulásuk A minta definíciói – a szótárak szerint A Magyar értelmező kéziszótár [1985] szerint a minta: „fn. 1. Olyasmi, aminek a méretei, formája stb. szerint készítenek hasonlókat.... 2. Öntőminta... 3. Ismétlődő dísz... 4. Áruból: egy darab vagy bizonyos mennyiség, amelyből az egésznek a jellege, minősége megállapítható.... |Tud Statisztikai vizsgálat céljára kiemelt kisebb tétel, amelyből az egészre következtethetünk. 5. Minta-, példakép. ...” A Webster [1987] értelmezőszótár szerint a pattern (minta): „1. A form or model proposed for imitation: EXEMPLAR.10 2. Something designed or used as a model for making things.11” Az Oxford számítástechnikai szótár [Oxford, 1986] szerint a minta: „függvényeken definiált speciális relációhoz kapcsolódó ekvivalenciaosztály. Minta- vagy alakfelismerés: ... A minták meghatározhatók analitikus módszerekkel, rendszerint azonban ún. sablonok segítségével, melyek az összehasonlítás során a modellminták szerepét töltik be.” Ez utóbbi definíció azért érdekes, mert a konkrét szoftvercsomagokban is fel lehet ismerni szoftvermintákat, és ez a mesterséges intelligencia technikáinak alkalmazásával a szoftvermintabányászat alapja lehet. A szótárak szerint a minták tehát általában konktétak – a minta lehet egy dolog, amihez hasonlót kell elképzelni vagy készíteni. Az utánzat összehasonlítható a mintával. A minta definíciói – a szoftverközösség szerint Christopher Alexander [1979] szerint minden egyes minta egy kapcsolatot fejez ki egy bizonyos környezet, egy probléma és egy megoldás között. A minta egyidejűleg egy dolog és az azt előállító eljárás leírása.”. Alexander továbbá ezt is írja [Alexander, 1977]: „Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”12

10 11 12

Utánzási célra javasolt formátum vagy modell. MINTAPÉLDÁNY. Valami, amit dolgok elkészítéséhez modellként terveznek vagy használnak. „A minta leír egy, a környezetünkben minduntalan előforduló problémát, aztán leírja a probléma megoldásának lényegét oly módon, hogy ezt a megoldást akár milliószor is használhatjuk anélkül, hogy ugyanaz a megoldás kétszer előfordulna.”

9

Angster Erzsébet: Doktori (PHD) értekezés, 2006 James O. Coplien a Bell Laboratories munkatársa a szoftvermintákról szóló „white paper” kiadványában a minta fogalmát röviden így adja meg: A minta az irodalom egy darabja, amely leír egy tervezési problémát, valamint a problémához megad egy általános megoldást egy adott környezetben [Coplien, 1996, pp. 2]. Coplien a „Minták honlapján” ezt írja: A szoftverminta közösség célja egy olyan törzsanyag építése, amely általános módon támogatja a szoftver tervezését és fejlesztését. A konkrét technológiákra kisebb hangsúlyt fektet; a lényeg annak a kultúrának a kialakítása, amely támogatja a szép, egészséges tervezést. [Hillside, 2003] Fowler [1997, pp. XV] szerint a minta egy ötlet, amely hasznosnak bizonyult egy gyakorlati környezetben, és valószínűleg más környezetekben is hasznos lesz. Buschmann et al. [1996] POSA (Pattern-Oriented Software Architecture) könyvében ez áll: Egy szoftverminta leír egy adott tervezési környezetben előforduló egyedi, visszatérő problémát; és megoldására ad egy jól kipróbált, általános sémát. Craig Larman [2002] szerint: A minták elvek és idiómák szótára, melyek kombinálhatók az objektumok megtervezéséhez. Egy másik rövid definíciója: A minta a működő dolgokban ismétlődő legjobb gyakorlatok – bármilyen területen. A fenti definíciók szerint tehát a szoftverminta egy adott szoftverfejlesztési környezetben gyakran előforduló probléma általános és jól dokumentált megoldása, melyet már több ember, több alkalommal kipróbált, és amely a legjobb gyakorlatnak bizonyult. A minta egy dokumentált környezet-probléma-megoldás trió. A minta leír tehát mindent, ami a probléma és a megoldás megértéséhez, valamint az adott környezetben egy másik, hasonló probléma megoldásához szükséges. „A minták legnagyobb előnye abban áll, hogy segíti a fejlesztőket a jobb kommunikációban.” [Fowler, 1997, Ralph Johnson előszava]. „A minták mindig a gyakorlatból kerülnek elő.” [Fowler, 1997, pXVII]. A minta bármilyen típusú lehet. A megoldás lehet egy osztályterv, egy leírás, egy algoritmus vagy bármi más. Knuth könyve, The Art of Computer Programming [Knuth, 1973] például egy algoritmusleíró minta-gyűjtemény. A minták nem korlátozódnak az objektumorientált paradigmára.

10

2. A szoftverminták és kialakulásuk A minta egy absztrakt leírás, mely megad egy tervezési problémát, valamint az elemek általános elrendezését, ahogy a problémát megoldják [Gamma et al., 1995]. A szoftverminta tehát nem egy futó alkalmazás vagy modul; nem egy konkrét fejlesztői vagy felhasználói dokumentáció; nem egy konkrét objektum vagy algoritmus. A szoftverminták tehát általánosak és absztraktak, azaz nem konkrétak. A szoftverminták osztályszerűek, nem valós világbeli egyedek.

2.5.

A szoftverminták ismérvei

Coplien [2003] szerint a jó minta 1. Megold egy problémát: A minta megoldásokat ad, nem csupán absztrakt elveket és stratégiákat. 2. Kipróbált fogalom: A minta nyomonkövethető megoldásokat ad, nem pedig elméleteket vagy spekulációkat. 3. A megoldás nem nyilvánvaló: Sok problémamegoldó technika (mint a szoftvertervezési paradigmák és módszerek) az elveket direkt módon alkalmazva keresi a megoldást. A legjobb minta indirekt módon generálja a megoldást, mely bonyolultabb tervezési problémák esetén elkerülhetetlen. 4. Kapcsolatot ír le: Nem csak egyszerű modulokat ír le, hanem mélyebb rendszerstruktúrákat és mechanizmusokat. 5. Tartalmaz emberi tényezőket és minimalizálja az emberi beavatkozást: Minden szoftver az ember kényelmét és életminőségét szolgálja; a legjobb minták nyíltan célozzák az esztétikát és a hasznavehetőséget. A szoftverminta minőségének értékeléséhez egy mintakonferencia résztvevői a következő kritériumokat fogalmazták meg [The Software Patterns Criteria, 1998]: Alapvető kritériumok (Ezek a kritériumok kötelezőek bármely szoftvermintára nézve. A sorrend nem számít.): 1. Hármas szabály: Egy mintát minimum háromszor kell használni: első használatakor megbizonyosodunk arról, hogy működik; második használatakor kiderül, hogy a megoldás

11

Angster Erzsébet: Doktori (PHD) értekezés, 2006 érdekes, harmadik használatakor pedig egyértelművé válik, hogy alkalmazható, és valóban egy jó minta. 2. Minta neve: A minta neve jellemző a dokumentált megoldásra, és egyedi a mintagyűjteményben. 3. Dokumentáció: A szoftverminta egy irodalmi forma, amely egy szoftver probléma dokumentált megoldását és a kapcsolódó tervezési erőfeszítéseket tartalmazza. 4. Tanítás: A szoftverminta tartalmaz mind megoldási, mind tanítási elemeket. A tanítási elemek adják meg a „miért?” kérdésekre a választ, ésszerű magyarázatokkal. 5. Bírálat: A szoftvermintát minősített szakemberek bírálják és elfogadják. A bírálat alapján a szerző javítja, átírja a mintát. Erősen ajánlott, hogy a mintát minél nagyobb csoport ellenőrizze és kommentálja. Kívánatos kritériumok (Ezek a kritériumok nem szükségesek, de kívánatosak bármely szoftvermintára nézve, a megadott prioritási sorrendben.): 1. Alapos megoldás: A megoldás meggyőzően és részletekbe menően válaszol a „mit” és „hogyan” kérdésekre. Kiadós segítséget nyújt a kezdő szoftvereseknek, illetve azoknak a szakembereknek, akiknek nincs gyakorlatuk ebben a megoldásban. A minta formális bemutatása a megoldást mind az absztrakt, mind a konkrét perspektívából definiálja. Más szavakkal, szerepelnie kell úgy az absztrakt leírásnak, mint a specifikus példának. 2. Sablon: A szoftverminta dokumentációját erősen ajánlott meghatározott részekbe szervezni. A szofverminta sablonnak tartalmaznia kell az összes kulcsfontosságú kérdést/ szempontot. A sablonnak minimálisan tartalmaznia kell a minta nevét, a problémát és a megoldást, ezen kívül erősen ajánlott a következő dolgok megadása: kontextus, kényszerek, valamint az eredmény kontextus (előnyök, következtetések). A minta jellegétől függően más-más felosztást ajánlanak a szerzők. Például Gamma et al. [1995] és Buschmann et al. [1996] mintái 14 részt, a CORBA tervezési minták [Mowbray, 1997] pedig 12 részt tartalmaznak. 3. Gyakorlati visszajelzés: A gyakorlati visszajelzés a szoftverminta hatékonyságának érvényesítése annak terjesztésekor. A gyakorlati visszajelzések olyan szakemberektől jön-

12

2. A szoftverminták és kialakulásuk nek, akik a mintát alkalmazták. A szoftverminta hozzá kell, hogy járuljon a sikeres és minőségi szoftverfejlesztési gyakorlathoz. 4. Széleskörű elfogadás: Ajánlatos, hogy minden szoftverminta legyen publikálva és legyen nyilvánosan elérhető. A szoftverminta és a katalógus széleskörű elfogadása és tudatossága objektív kritériumok alapján mérhető ugyanúgy, mint az osztálytermi felmérések.

2.6.

Mintasablonok

A minta írására különféle mintasablonok (pattern templates) terjedtek el. Egy mintasablon a minta dokumentálásához egy meghatározott felosztást ajánl. A mintasablonokra vonatkozó javasolt, alapvető kritériumokat a Szoftverminta kritériumok dokumentum tartalmazza [The Software Patterns Criteria, 1998]. Széleskörűen elfogadott sablonok például az Alexander féle sablon, a „Pattern writing” sablon, a Négyek féle (GOF) sablon, a Portland féle sablon, az AGS sablon és a Fowler sablon. Egy minta linkgyűjtemény szerepel az [SDP, 2004] lapon. Alexander féle sablon (Alexandrian form) Alexander [1977] könyve, A Pattern language építészeti mintákat tartalmaz. Alexander a következő sablon szerint adja meg mintáit (a szögletes zárójel jelzi, hogy a sablon nem tartalmazza a rész címét, csak annak leírását): Sablonrész neve angolul magyarul [Pattern Minta neve name] [Picture] [Context]


[Problem] [Body]

Kép Környezet Probléma Törzs

Therefore: [Solution]

Ezért: Megoldás

[Diagram]


[Related patterns]

Ábra Kapcsolódó minták

Magyarázat A minta neve vastagon szedve. Utána 0..3 csillag, mely a megoldás határozottságát jelöli: Nulla csillag: az itt megadott megoldáson kívül lehetnek más megoldások is. Három csillag: az itt megadott megoldás kötelező. Egy kép, mely jellemző a mintára. Bevezető paragrafus, a környezet leírása. Elején három pont. Elválasztó sor A probléma lényege. Egy-két mondat, vastagon szedve. A probléma törzse. A probléma részletes kifejtése: háttér, motiváció, variációk. Ez a leghosszabb rész. Kötött szó, a megoldási rész előtt. A probléma megoldása. Részletes, de általában rövid. Vastagon szedett. A megoldás képi ábrázolása. Elválasztó sor A kapcsolódó minták megadása egy szövegkörnyezetben. Utána három pont. 13

Angster Erzsébet: Doktori (PHD) értekezés, 2006 Az Alexander sablon nem tartalmaz kötött szavakat (kivéve a Therefore-t), ezért bizonyos szakterületeken –, mint például a szoftverfejlesztés egyes területei – nehezebben követhető forma. A pedagógiai minták elfogadott sablonja jelenleg az Alexander sablon. Mintaíró sablon (Pattern writing form) A szoftverközösség mintaírási gyakorlatához Meszaros és Doble kidolgoztak egy mintanyelvet: „Pattern Language for Pattern Writing” [Meszaros et al., 1998]. A szoftverminta gyűjtemények többsége lényegében ezt a formát használja. Eszerint a mintának vannak általánosan elfogadott kötelező részei, és vannak opcionális részei. Kötelező részek: Sablonrész neve angolul magyarul Pattern Minta neve name

Context

Környezet

Problem

Probléma

Forces

Kényszerek

Solution

Megoldás

Magyarázat A minta egyedi azonosítója. Ezzel a probléma/ megoldás párra egyértelműen hivatkozni lehet. A minta neve jellemző a mintára és könnyen megjegyezhető. A név egy főnév, sokatmondó, emlékeztető metafora. Lehetőség szerint a megoldásra utaljon. A probléma környezete; az a kontextus, melyben a minta hasznos. Megadja, mikor lehet alkalmazni a mintát. Leírja a megoldandó problémát. Egy állítás vagy kérdés, amelyet ez a minta megold. A problémára és a megoldásra ható kényszerítő tényezők. Leírja a megoldás elemeit, az elemek kapcsolatait, felelősségeit és együttműködéseit. A megoldás általános, vagyis sok konkrét esetre alkalmazható.

Nem kötelező részek:

14

Indications

Jelek

Resulting context

Eredmény környezet

Related patterns Examples

Kapcsolódó minták Példák

Olyan jelek, szimptómák, melyek rámutathatnak a probléma létezésére. Más néven: Következmények (consequences). Eredmény környezet, mely a minta alkalmazása után keletkezik. Megadja a minta alkalmazásának előnyeit és hátrányait; a rendszer rugalmasságára, kiterjeszthetőségére és hordozhatóságára gyakorolt hatását. Más minták, melyek hasznosak lehetnek az olvasó számára. Más néven: Known Uses. Konkrét példák, melyek illusztrálják a minta alkalmazását.

2. A szoftverminták és kialakulásuk Code Samples Rationale

Kód minták

Aliases Acknowledgments

Más néven... Köszönet

Magyarázat

Minta kódok, melyek mutatják, hogy a mintát hogy kell, illetve lehet implementálni. Rámutat, hogy a szóbanforgó problémának miért pont ez a helyénvaló megoldása. Más nevek, amelyeken ez a minta ismeretes lehet. Elismerés, köszönet azoknak, akik valamilyen módon hozzájárultak a mintához. A shepherd (pásztor) tipikusan ilyen.

Négyek féle sablon (GOF form) A Design Patterns könyv [Gamma et al., 1995] tartalmazza az elsőnek megjelent tervezési mintákat. A könyvükben szereplő minták sablonját GOF (Gang Of Four) formának nevezték el. A sablonnak 13 része van, mindegyiket egy-egy kötött szó után kell kifejteni. Részei: Pattern name, Intent, Also known as, Motivation, Applicability, Structure, Participants, Collaborations, Consequences, Implementation, Sample code, Known uses, Related patterns. A GOF minták magyar fordításban is megjelentek [Gamma et al., 1995a]. Portland sablon (Portland form) Nevét onnan kapta, hogy kezdeti használói mind Portlandból (Oregon) származtak. A Portland Patterns Repository [Portland, 2003] mintáit ebben a formában írták meg. A Protland sablon egy szabad forma, ahol nincsenek határozott résznevek. A minta a következő részeket tartalmazza: [Pattern name], [Problem], Therefore:, [Solution], [Summary] AGCS sablon (AGCS form): A minta az AG Communications Systems sablonja [AGCS, 2003; Rising, 1998]. A sablon első változata a Coplien sablon volt. Nagyon elterjedt minta, a Hillside group egyik ajánlott sablonja [Hillside, 2003]. Részei: Pattern name, Aliases, Problem, Context, Forces, Solution(s), Resulting Context, Rationale, Known Uses, Related Patterns, Sketch, Author(s), Date, E-mail, References, Keywords, Example. A felsorolt részek közül kötelező a Problem, a Context és a Solution. A Pattern Languages of Program Design sorozat [Coplien et al., 1995; Vlissides et al., 1996; Martin et al., 1998; Harrison et al., 2000] mintáinak többsége az AGCS sablon szerint íródott.

15

Angster Erzsébet: Doktori (PHD) értekezés, 2006 Egyéb sablonok Martin Fowler Analysis Patterns könyvében [Fowler, 1997] nem használ sablont. A 2004es átdolgozott kiadásban [Fowler, 2003d] azonban az elemzési mintákat a következő sablon szerint írja: Name (minta neve), Intent (szándék), Sketch (vázlat), Examples (példák), How it Works (hogyan működik), When to use it (mikor használandó), Sample Code (példa kód). Craig Larman Applying UML and Patterns könyvében [Larman, 2002] a GRASP mintákat a következő bontásban adja meg: Name (minta neve), Solution (megoldás), Problem (probléma), Example (példa), Discussion (megvitatás), Contraindications (ellenérvek), Benefits (előnyök), Related patterns or Principles (kapcsolódó minták vagy elvek), Also Known as / Similar To (Más néven / Hasonló minta). A fentiekből látszik, hogy bár sokan törekednek a minta sablonjának szabványosítására, a szerzők nem használnak univerzális sablont. Ez valószínűleg azért van, mert a minta felépítése erősen függ a probléma jellegétől. Végül fontos megjegyezni, hogy a mintaírási stílus és sablon nincs közvetlen hatással a minta sikerességére. A fontos az, hogy szerepeljenek benne az alapelemek: a probléma, a kontextus, a megoldásra ható kényszerek, és ami a legfontosabb: egy konkrét megoldás előterjesztése [Coplien et al., 1995] .

2.7.

Minta szakterületek

Minták bármely szakterületen (domain) használhatók. Lehetséges szakterületek például az építészet, vegyészet, matematika, közgazdaság-tudomány, gasztronómia, pedagógia, vagy a szoftverfejlesztés. Szakterület-specifikus minták az üzleti, a szállítási vagy a tűzriasztó rendszerekkel kapcsolatos minták is. A szakterületeknek lehetnek részterületei is. A szoftverfejlesztés részterületei például: Fejlesztési eljárás, Dokumentálás, Felhasználói felület, Adatbázis, J2EE stb. A minta szakterületek természetesen szükség esetén keverhetők.

2.8.

A minta absztrakciós szintjei

A szoftverminta absztrakciós szintje (abstraction level) lehet magas, ami egy durva de meghatározó elképzelést, illetve nagyvonalú tervet jelent; és lehet alacsony, ami a részletes kidolgozást, megvalósítást jelenti. A különböző szerzők között nincs teljes egyetértés az

16

2. A szoftverminták és kialakulásuk absztrakciós szintek meghatározásában. A szoftvermintákat a legtöbb szerző három kategóriába sorolja: implementációs (kód), tervezési és architekturális. Coplien [1996] szerint ezzel a besorolással két probléma is van: az egyik, hogy a határok nem pontosak, s így a besorolás szubjektívvé válhat; a másik, hogy bizonyos minták felölelhetik mindhárom absztrakciós kategóriát – ilyen például az MVC minta. További probléma, hogy nem minden esetben világos az architektúra, a terv, illetve az implementáció fogalma. Vannak olyan minták, melyeknél az alacsony szint kizárólag részletezést jelent, kód sosem tartozik hozzá – ilyenek például a mintakészítés mintái [Meszaros et al., 1998]. Jelen disszertáció szerzője az SDP-cityben három absztrakciós szintet különböztet meg: az alacsony (low), a közepes (medium), és a magas (high) szinteket.

2.9.

A mintacsomag teljessége

Mintacsomagnak vagy mintakollekciónak nevezzük a fizikailag egy helyen tárolt mintákat. A mintacsomag elemei (mintái) valamilyen szempontból összetartoznak, az elemek között általában logikai kapcsolatok vannak. A mintacsomagot osztályozhatjuk annak teljessége (completeness) szerint. Egy teljes mintacsomag a szóbanforgó rendszert teljesen leírja, és az elemek között erős összetartás (high cohesion) van. Teljesség szerint beszélhetünk önálló mintáról, katalógusról, rendszerről, nyelvről és kultúráról. 13 Önálló minta (single pattern) Önálló mintának nevezünk egy mintát, ha az nem kapcsolódik más mintákhoz. Az önálló minták nem teszik lehetővé egy teljes szoftver-architektúra részletes felépítését; legfeljebb segítenek az alkalmazás tervezésében egy adott szempontból [Buschmann et al., 1996]. Mintakatalógus (pattern catalog) A teljes szoftver megtervezéséhez különféle mintákra van szükség. Minél szélesebb és jobb a választék, annál színvonalasabb lehet a teljes megoldás. Ahhoz, hogy a minták kezelhetők, visszakereshetők legyenek, valahogy csoportosítanunk, osztályoznunk kell azokat. A minta-

13

A mintacsomag és a teljesség fogalmát itt vezetem be, mivel a szakirodalomban nem találtam egyértelmű elnevezést. A szakirodalom a minták osztályozásáról, kategorizálásáról stb. beszél, és körülírja a fogalmakat.

17

Angster Erzsébet: Doktori (PHD) értekezés, 2006 katalógus a legalacsonyabb szintű csoportosítás. A mintákat összetartja valamilyen közös tulajdonság, mint például a szakterület – így például beszélhetünk adatbázis mintákról, felhasználói interfész mintákról vagy dokumentálási mintákról. A Design Patterns könyv [Gamma et al., 1995] egy katalógus: tervezési minták katalógusa az alkalmazási keretrendszerek szakterületből. A könyv a tervezési mintákat három alcsomagba (al-kategóriába) sorolja: létrehozási, strukturális és viselkedési mintákra. Az Analysis Patterns könyv [Fowler, 1997] szintén katalógus: a szerző összegyűjtötte az általa gyakran használt elemzési (analízis) mintákat, de közel sem fedi le a különböző szakterületek lehetséges mintáit. Mintarendszer (pattern system) A hatékony használathoz a mintákat rendszerezni kell. A mintarendszer a mintákat egységesen írja le, osztályozza őket, és ami a legfontosabb, megmutatja, hogyan fonódnak össze [Buschmann et al., 1996]. A mintarendszerben a minták között strukturális kapcsolatok vannak: társítás, tartalmazás, általánosítás, függés, realizáció stb. A mintanyelvvel ellentétben azonban egy mintarendszer nem teljes. A Design Patterns könyv végén egy diagram található, amely a könyv mintáit és az azok közti kapcsolatokat tartalmazza – bár ezek a tervezési minták a szerzők szerint mindössze egy katalógust alkotnak. Mintanyelv (pattern language) A mintanyelv egy olyan mintarendszer, amely egy adott környezetben teljes – a benne található minták segítségével meg lehet oldani a környezetben felmerülő problémát. Néhány szerző definíciója a mintanyelvre: „A pattern language defines a collection of patterns and the rules to combine them into an architectural style. Pattern languages describe software frameworks or families of related systems.”14 [Coplien, 2003] „A pattern language for software architecture must be computationally complete: at least one pattern must be available for every aspect of the construction and implementation of software systems...” 15 [Buschmann et al., 1996].

14 15

A mintanyelv definiál egy mintagyűjteményt, s a mintákat architekturálisan összetartó szabályokat. A mintanyelvek szoftver keretrendszereket és egymáshoz kapcsolódó rendszer-családokat ír le. Egy szoftver architektúrához készített mintanyelvnek számítástechnikailag teljesnek kell lennie: a szoftverrendszerek építésének és megvalósításának minden aspektusához elérhetőnek kell lennie legalább egy mintának...

18

2. A szoftverminták és kialakulásuk Mintanyelvre mindössze néhány széleskörűen elfogadott példa létezik. Ilyen például az Objektum–RDBMS integációjára készült mintanyelv [Brown et al., 1995]. Coplien 1998 januárjában az OMO-nak adott interjújában [Coplien, 1998] a „Mi a kedvenc mintája?” kérdésre a következő választ adta: Manapság az önálló minták sokkal kevésbé érdekelnek már, mint a mintanyelvek. Szerintem Ward Cunningham CHECKS mintanyelve [Cunningham, 1994] az egyik legjobb és legpéldamutatóbb mintanyelv tartalmában, formájában és interpretációjában egyaránt. Vitás kérdés, hogy mely mintakatalógus nevezhető mintarendszernek, és mely mintarendszer nevezhető mintanyelvnek. Sok szerző meglehetősen lazán használja e fogalmakat. Mintakultúra (pattern culture) A mintakultúra a minták legmagasabb szintű összetartozása. A mintakultúra mintanyelvekből, és az azok közötti kapcsolatokból áll. A szoftvervilágban egyelőre nincsen példa mintakultúrára.

2.10. Implementációs minták Az implementációs minták alacsony absztrakciós szintű minták, melyek speciális implementációs technikáktól – mint például a programozási nyelvtől – függenek [Coplien, 1996, pp. 23]. Az implementációs mintákat (implementation pattern) a szakirodalom idiómáknak (idiom) is nevezi. A leggyakrabban emlegetett idióma talán Coplien Counted body mintája, mely szintén ebben az irodalomban található.

2.11. Tervezési minták A tervezési minták (design pattern) közepes absztrakciós szintű minták; egy szinttel feljebb vannak, mint az idiómák. A tervezési minták (design patterns) olyan osztálystruktúrák és objektum-együttműködések, amelyeket a programozók hasznosnak ítélnek és ezért érdemes katalogizálni. A probléma, a kényszerítő körülmények és a megoldás nyelvfüggetlenek, így a tervezési minták a szoftverproblémák általános tervezési gyakorlatai [Coplien, 1996, pp. 24]. A tervezési mintákat az 1995-ben megjelent Design Patterns könyv [Gamma et al., 1995] tette ismertté. A könyv néhány év alatt a számítástechnikai könyvek bestseller-jévé vált. A

19

Angster Erzsébet: Doktori (PHD) értekezés, 2006 négyek egy 1993-as cikke szerint a minták a tervezési alapelveknek egy közös szótárát és megértését biztosítják [Gamma et al., 1993]. Ez a könyv a leggyakrabban használatos tervezési mintákat katalogizálja. Bár a fejlesztők nagy része e mintákat már a könyv megjelenése előtt is széleskörűen alkalmazta, a könyv megjelenésével a minták nevet kaptak, használatuk tudatossá vált, egyszerűbb lett a fejlesztők közötti kommunikáció. A tervezési minták mikroarchitektúrák: olyan szerkezetek, amelyek az objektumoknál nagyobbak, de nem elég nagyok ahhoz, hogy rendszerszintű törvényszerűségeket adjanak meg [Buschmann et al., 1996]. A Design Patterns könyv szerzői a tervezési mintakatalógus mintáit három típusba sorolják: − A létrehozó minták (creational patterns) használatával a rendszer függetleníthető az objektumok létrehozási mechanizmusaitól. Ilyen például az Abstract Factory vagy a Prototype. − A strukturális minták (structural patterns) az objektumok, illetve osztályok közötti kapcsolatokkal foglalkoznak. Ilyen például a Composite vagy a Decorator. − A viselkedési minták (behavioral patterns) az objektumok, illetve azok együttesének viselkedésével, a bennük levő algoritmusokkal és a felelősség szétosztásával foglalkoznak. Ilyen például a Command és az Observer. A Design Patterns könyv szerzői szerint: a könyvben katalogizált minták mindegyike kipróbált, azokat több mint egyszer használták. A könyv – mérete ellenére – csak egy kis részét fedi le azoknak a tervezési mintáknak, melyekre egy szakembernek szüksége van. Nem tartalmaz például mintákat a párhuzamos, elosztott vagy valós idejű programozásra, és nem tartalmaz egyetlen szakterület-specifikus mintát sem. [Gamma et al., 1995] A Design Patterns könyv egy jó kiindulópont, illetve tananyag a tervezési minták filozófiájának megismeréséhez és a minták használatához. A könyv mintái ma már a legtöbb programnyelvi könyvtárba be vannak építve. Az MVC architektúrán alapuló felhasználói interfészek például többek között a Composite, Observer, Strategy és a Factory method mintákból építkeznek. Ezeket a mintákat tehát a fejlesztő automatikusan is használja. A 23 GOF tervezési mintából kb. 15-öt használnak gyakrabban a fejlesztők [Larman, 2002].

20

2. A szoftverminták és kialakulásuk További tervezési mintákat tartalmaz köbbek között a Pattern Languages of Program Design sorozat [Coplien et al., 1995; Vlissides et al., 1996; Martin et al., 1998; Harrison et al., 2000].

2.12. Architekturális minták Az architekturális minták (architectural pattern) magas absztrakciós szintű minták. Egy architekturális minta egy szoftver-rendszer alapvető, legmagasabb szintű szervezését (rendszerszintű elrendezését, összefüggéseit, törvényszerűségeit) adja meg. Architekturális minták már a Pattern Languages of Program Desing első kötetében megjelentek [Coplien et al., 1995]. Az első, csak architekturális mintákról szóló könyv a POSA (Pattern-Oriented Software Architecture) könyv [Buschmann et al., 1996]. A szerzők szerint: az architekturális minta kifejezi a szoftver-rendszer alapvető strukturális szervezési sémáját. Előre megadja az alrendszerek egy halmazát, specifikálja azok felelősségeit, valamint szabályokat és irányelveket tartalmaz az alrendszerek közötti kapcsolatok szervezésére. Az architekturális minták tehát rendszer-szintű minták – magas szintűek, globálisak. A keretminta (framework pattern) is rendszer-szintű minta. Coplien [1996] szerint a keretminta egy csontváz, melyet ki lehet egészíteni (be lehet fejezni), hogy egy konkrét alkalmazásterv váljék belőle. Mary Shaw [1995, 1996] szerint a szoftver-rendszerek különböző típusú, azonosítható komponensekből építkeznek, melyek jól meghatározott módon kommunikálnak egymással. Egy architekturális minta adott típusú komponensekből és együttműködési szabályokból áll. Shaw szerint a leggyakoribb architekturális minták a következők: Pipeline, Data abstraction (object-oriented), Implicit invocation (event based), Repository, Interpreter, Main program and subroutines, Layered Architecture. Egy szoftverfejlesztő ezeket a mintákat kombinálva állítja össze a rendszer architektúráját. Egy gyakran hivatkozott könyv a POSA [Buschmann et al., 1996], melyben a szerzők az arhitekturális mintát így definiálják: „Az arhitekturális minták a szoftver-rendszerek alapvető strukturális szervezésének sámái. Megadnak egy halom előredefiniált alrendszert, megadják azok felelősségét, valamint szabályokat és útmutatásokat adnak a köztük levő kapcsolatok szervezéséhez.”

21

Angster Erzsébet: Doktori (PHD) értekezés, 2006 A POSA könyv az architekturális mintákat négy kategóriába sorolja: From Mud to Structure, Distributed Systems, Interactive Systems és Adaptable Systems.

2.13. Elemzési minták Az elemzési vagy analízis minta (analysis pattern) magas absztrakciós szintű minta; a feladat megoldásának fogalmi szintű, logikai, szakterület-specifikus (azaz nem szoftvertechnológiai) megközelítése. Az elemzési minták a szakterületi modellek (domain model) jól bevált darabkái. Az elemzési minták az elemzés munkafolyamat termékei; azok az üzleti folyamatok koncepcionális struktúráit, modellezési alapelveit mutatják be. Elemzési minták elsőként Martin Fowler könyvében jelentek meg [Fowler, 1997]. A könyv első részében az elemzési minták szakterületek szerint vannak kategorizálva (Felelősség, Megfigyelés és mérés, Raktározás és számlázás, Kereskedelem stb.). A könyv második része arról szól, hogyan lehet a mintákat egy információs rendszer architektúrájába illeszteni. Szintén szakterületi mintákat mutat be Hay és Barker, Data Model Patterns című könyvükben [Hay, 1996]. A Pattern Languages of Program Design sorozat 3. kötetének egyik részében (Domainspecific Patterns) három elemzési mintagyűjtemény kapott helyet: egy a kapcsolati objektumok üzleti modellezésével, egy a szállítmányozással, egy pedig a tűzriasztással kapcsolatos [Martin et al., 1998, p391]. A bevezető szövegben ez áll: „A publikus minták legtöbbje technikai szakterületeket céloz meg, mint például valós idejű vagy osztott rendszerek, perzisztencia, stb. Azonban a felhasználók többsége nem ezt a tudást akarják tőlünk közvetlenül megvásárolni, hanem magát a probléma megoldását. Olyan mintákra is szükég van tehát, amelyek a sikeres üzleti rendszerek tervezését és architektúráját dokumentálják.” 2.14. GRASP minták A GRASP (General Responsibility Assignment Software Patterns, Általános felelősségleosztási szoftverminták) egy mintakollekció, mely általános elveket és útmutatásokat ad a szoftver tervezési modelljének (csomagszerkezetének és osztályainak) kialakításához. A GRASP minták16 gondolatai nem újkeletűek; a bennük megfogalmazott elvek érvényesítése,

16

Helyesen „GRAS minta” lenne, de a fogalom így terjedt el, valószínűleg a „GRASP minta” jobb hangzása miatt.

22

2. A szoftverminták és kialakulásuk használata a minőségi szoftver kialakításának elengedhetetlen feltétele. A betűszó extra jelentése (grasp, fogás) is arra utal, hogy ezek az elvek jó fogások a tervezés folyamatában. A GRASP hét mintából áll: Information Expert, Creator, Controller, High Cohesion, Low Coupling, Polymorphism, Indirection, Protected Variations és Pure Fabrication. A fejlesztőnek egyszerre több GRASP mintát is figyelembe kell vennie, ilyenkor súlíoznia kell.

2.15. Pedagógiai minták A pedagógiai minták szakterülete a tanítási/tanulási folyamat – bármilyen absztrakciós szinten. A tanításban ismételten előforduló problémák például a tanuló motiválása, a tananyag megválasztása, a tematika kialakítása, az elmélet és gyakorlat arányának meghatározása, értékelés, vizsgáztatás stb. Nincs olyan gyakorlott tanár, akinek ne lehetne újabb ötleteket adni, illetve nem lehetne bővíteni módszertani tárházát. A legtöbb kezdő oktató pedig kifejezetten igényli az oktatás módjára vonatkozó ötleteket. Egy pedagógiai minta a gyakorlatban jól bevált tanítási, illetve tanulási módszert mutat be. Pedagógiai minták már a Pattern Languages and Program Design 2. kötetében [Vlissides et al., 1996] megjelentek: Dana L. G. Anthony tizennégy pedagógiai mintát írt le Patterns for Classroom Education címmel [Anthony, 1996]. Elöl szerepelnek az elvontabb minták (pl. Iterative Course Development), azután következnek a kicsit konkrétabb minták, mint (Chicken and Egg, Mix New and Old...). A végén szerepelnek a valós élethez legközelebb álló minták (Visible Checklist, Acquaintance Examples, Reference Examples, Colorful Analogy...). Susan Lilly az Object Magazine-ban [Lilly, 1996] az Újrahasználható pedagógiai tervezési mintákról ír. Lilly szerint a pedagógiai mintának ismételhetőnek és könnyen adaptálhatónak kell lennie. A jó mintát különböző tanárok különböző órákon könnyen „példányosítják”. Az 1996-os [OOPSLA] konferencia Pedagogical Patterns: Successes in Teaching Object Technology workshopja célul tűzte ki a pedagógiai minták összegyűjtését. A workshop leírása így kezdődik: „Bár az objektumorientált konferenciákon eddig sok jó pedagógiai ötlettel találkozhattunk, melyek minden évben meg is jelentek az újságokban és kiadványokban, még senki nem tett erőfeszítést arra, hogy ezeket a jó oktatói gyakorlatokat összegyűjtse.” A Pedagogical Pattern Project tehát 1996-ban indult [PPP, 1996]. A mintákat a projekt szervezői elsősorban az ECOOP (European Conference on Object-Oriented Programming), OOPSLA (Object-Oriented Programming, Systems, Languages and Applications), TOOLS 23

Angster Erzsébet: Doktori (PHD) értekezés, 2006 (Technology of Object-Oriented Languages and Systems) és az OT (Object Technology) konferenciákon gyűjtötték össze oktatási műhelymunkákon. 1998-ban megjelenik Manns et al. [1998] cikke: Capturing Successful Practices in OT Education and Training. A pedagógiai minták egy előgyűjteménye a [PPP, 1996] website-on található: The Pedagogical Patterns Project. Successes in Teaching Object Technology (Proto-Patterns), melyen a szerzőnek is van egy mintája: Pedagogical Pattern #47: Simple and Complete Patterns Step by Step [Angster, 1997]. A pedagógiai előminta sablonja a következő: Sablon rész

Magyarázat

NAME DATE

A minta neve Legutolsó módosítás dátuma A minta szerzője A minta rövid leírása (absztrakt) Probléma, kihívás, kérdés

AUTHOR THUMBNAIL PROBLEM / ISSUE AUDIENCE / CONTEXT FORCES SOLUTION DISCUSSION SPECIAL RESOURCES CONTRAINDICATIONS RELATED PATTERNS EXAMPLE INSTANCES

Célzott közönség Mitől probléma a probléma? A probléma megoldása Az eredmény. Következtetések, megvalósítások Szükséges speciális erőforrások Mikor nem használható a minta? Hivatkozott minták

A minta konkrét alkalmazásai (ki, mikor, hogyan stb.) REFERENCES / Hivatkozások, köszönetACKNOWLEDGEMENTS nyilvánítások

Pattern Writing megfelelő Pattern name

Indications Problem Context Forces Solution Resulting context Context Rationale Aliases Related patterns Examples, Code Samples Acknowledgments

A pegagógiai minta projekt tagjai az előmintákat átdolgozták, és új weblapot nyitottak [PPP, 2003]. A minta fogalmának tisztulásával, a tapasztalatok gyűjtésével és az igények felmérésével a csoport arra a következtetésre jutott, hogy a meglévő pedagógiai minták túl nagy területet fognak át, ezért azokat mintanyelvekbe kell rendszerezni [Sharp et al., 2000]. Az

24

2. A szoftverminták és kialakulásuk előminták legtöbbje itt megjelenik átdolgozott, javított formában. Az új oldal sajnos nem olyan szervezett, mint elődje, az itt levő minták közt nehézkes a keresés. A pedagógiai minták véglegesen elfogadott sablonja az Alexander sablon. Sokak szerint ez a sablon nehezen olvasható, azonban Joe Bergin ezt írja: „For design patterns an outline form may be better, but for patterns with a human dimension – those intended for people other than programmers – Alexandrian works well.”17 [Bergin, 2003] 2.16. Mintakonferenciák, mintakészítés, pásztorkodás A PLoP (Pattern Languages of Programs) konferenciasorozatot a [Hillside, 2003] csoport hozta létre kifejezetten a programkészítési minták készítésére és terjesztésére. Az első PLoP konferencia 1994-ben volt, és azóta folyamatosan, több földrészen is megrendezésre kerülnek: PLoP (USA, Monticello, Illinois), EuroPLoP (Németország, Irsee), ChilliPLoP (USA, Arizona), KoalaPLoP (Ausztrália, Melbourne), MensorePLoP (Japán, Okinawa), SugarLoafPLoP (Rio de Janeiro, Brazilia), VikingPLoP (Skandinávia). A konferenciasorozat célja, hogy a mintaírók a mintáikat kritikai ellenőrzési folyamatnak vethessék alá. A minta szerzője elkészíti a mintát vagy mintagyűjteményt, melyet először egy pásztorkodási (shepherding) folyamatnak kell alávetni. A mintát a PLoP konferencia Writer's workshop résztvevői hagyják véglegesen jóvá. A legtöbb publikált mintát a PLoP konferenciákon hagyják jóvá. Az Addison Wesley könyvkiadónak van egy szoftverminta sorozata (Software Pattern Series – SPS), ezek közül való a PLoPD (Pattern Languages of Program Design) sorozat is, melynek eddig 4 kötete jelent meg: [Coplien et al., 1995; Vlissides et al., 1996; Martin et al., 1998; Harrison et al., 2000]. A PLoPD könyvsorozat szerkesztői a PLoP konferenciákon jóváhagyott mintákból válogatnak. A minta PLoP konferencián való elfogadása még nem garantája a minta PLoPD-ben való publikálását. Bizonyos konferenciaanyagok online proceedings formájában megtalálhatók a hálón.

17

„Tervezési mintákra talán jobb a vázlat forma, de az olyan minták esetén, amelyek emberi dimenziókat is tartalmaznak – amelyek nem programozóknak készülnek – az Alexander minta jól működik.”

25

Angster Erzsébet: Doktori (PHD) értekezés, 2006 Minta írása A minták írásához készült egy mintanyelv [Meszaros, 1998], amely a mintaírás általános szabályait és ajánlásait tartalmazza. Pásztor (shepherd) és a pásztorkodási eljárás (shepherding) A pásztorkodási vagy terelgetési eljárás lényegében egy ellenőrzési, javítási folyamat. A pásztor (shepherd) egy mintaírási tapasztalattal rendelkező személy, akit hozzárendelnek egy mintát író személyhez, vagyis a szerzőhöz azzal a határozott céllal, hogy segítse őt a minta megírásában, illetve javításában [Hillside, 2003]. Writer's workshop A writer's workshop (írók műhelymunkája) gyakorlatát a szoftverközösség egy már évtizedekkel ezelőtt elterjedt, meglévő gyakorlatból vette át. A gyakorlatot egy kreatív írási közösség kezdeményezte azzal a céllal, hogy az új írók csiszolhassák írási készségüket és stílusukat a gyakorlott írók ajánlásai alapján. A szoftverközösségben ezt a gyakorlatot először Richard Gabriel vezette be az 1994-es PLoP konferencián. A Writer's workshop a PLOP konferencia egyik fő jellegzetessége. A writer's workshop adott forgatókönyv alapján zajlik: a mintákat minden résztvevőnek előre el kell olvasni. A mintaírók munkáit kis csoportok tárgyalják, megvitatják erősségeit, gyengéit. A szerző a vita nagyobb részében csupán megfigyelőként szerepelhet. [Rising, 1998]

2.17. A minták használatának fontossága „Másoktól tanuld meg, mit kell tenned, s mit elhagynod; a jó élethez így példamutatást kapsz.” Latin bölcsesség A minta a szoftverfejlesztő kaptafája A szoftverfejlesztő csak akkor lehet hatékony, ha munkájának nagy részében a már meglévő mintákat alkalmazza, variálja, továbbfejleszti. Egy mintát felesleges sokszor feltalálni; a ráfordított energiát új feltalálásokra, új minták gyártására is lehet fordítani. A minták felhasználásával a fejlesztő nem veszti el kreativitását, hiszen a megoldandó feladatok száma végte-

26

2. A szoftverminták és kialakulásuk len. Ahogy a suszter nem tud dolgozni kaptafa nélkül, úgy a szoftverfejlesztő sem tud dolgozni mintagyűjtemény nélkül. Ralph Johnson és Ward Cunningham írja [Coplien et al., 1995] előszavában: „A rutinszerű megoldások hiánya miatt a prokektek a legújabb technológiák ellenére is megbuknak.” A minta az egységesítés eszköze A minták a szoftverfejlesztők közös, egységes nyelve. „A minták legnagyobb előnye abban áll, hogy segíti a fejlesztőket a jobb kommunikációban.” [Fowler, 1997, Ralph Johnson előszava]. Larman [2002] ezt a gondolatot egy fejlesztő képzeletbeli szavaival teszi szemléletessé: „I suggest a Strategy generated from a Factory to support Protected Variations and Low Coupling with respect to X.”18 A minta növeli a biztonságot Még a legtriviálisabb feladat esetén is megnyugtató a minta használata. Mindenkit érdekel, hogy más hogy csinálja, kell a visszacsatolás. Fowler [1997, pp. 12] szerint „A minták nagyon fontos szerepet játszanak a saját és mások munkáinak felülvizsgálatában.” A minta javítja a minőséget A minták használata a szoftver-újrafelhasználással a szoftverfejlesztés minőségének javítását célozza. A minták terjesztésével a Hillside csoport elsődleges célja a szoftverfejlesztés minőségének javítása [Hillside, 2003]. A szoftverminta hozzá kell, hogy járuljon a sikeres és minőségi szoftverfejlesztési gyakorlathoz [The Software Patterns Criteria, 1998]. Minden szoftver az ember kényelmét és életminőségét szolgálja; a legjobb minták nyíltan célozzák az esztétikát és a hasznavehetőséget [Coplien, 2003]. A szoftverfejlesztésben is érvényes Alexander híres „The Quality without a Name” mintája [Alexander, 1979], aminek az a lényege, hogy egy rendszer akkor is lehet minőségi, ha annak nem tudjuk megnevezni a minőségi kritériumát. A név nélküli minőséget egyszerűen érezzük [Coplien, 1996, pp. 34.].

18

„Azt ajánlom, hogy itt használjunk egy, a Factory-val generált Strategy-t, támogatva ezzel a Protected Variations és Low Coupling elveket, figyelembe véve X-et.”

27

Angster Erzsébet: Doktori (PHD) értekezés, 2006

28

3. A kutatás folyamata, első eredmények

3.

A kutatás folyamata, első eredmények ”We've got big trouble in Software City.” [Gill, 2000, Chapter 2.]

3.1.

A kutatás folyamata

Ebben a pontban bemutatom a teljes kutatás folyamatát és állomásait, valamint ismertetem az első eredményeket. A kutatás előtt – a 2001/2002-es tanévben – egy kísérleti szoftverfejlesztési tantárgy tananyagának összeállításakor úgy láttam, hogy nem állnak rendelkezésre megfelelő tananyagok, és a piacon nem lehet találni konkrét szoftverfejlesztési példákat. Szoftvermintákat alkalmazó példákat még kevésbé találtam. Ezért a témában előzetes kutatásokat és felméréseket végeztem: − Interjúkat készítettem szoftverfejlesztőkkel, oktatókkal, tanulókkal és menedzserekkel; − Létrehoztam az országos Abakusz szoftverfejlesztő versenyt, hogy megvizsgálhassam a beadott munkákat; − Nemzetközi workshopot hoztam létre, hogy tájékozódhassak a szoftverfejlesztést oktatók körében. Ezután széleskörű irodalomkutatást folytattam, és felfedeztem az „ördögi kört”. Közben felállítottam a mintahasználattal kapcsolatos hipotéziseimet. Más kutatásokat felhasználva (szoftverminta-, DOI, SPI kutatás) kialakítottam a mintahasználatot befolyásoló tényezők modelljét. A modell alapján egy felmérést végeztem a magyarországi szoftverminta-használatról. Ehhez összeállítottam a kérdőívet, kidolgoztam az adatgyűjtési technikát, majd internetes kérdőívek segítségével adatokat gyűjtöttem. A kérdőívek érté-

29

Angster Erzsébet: Doktori (PHD) értekezés, 2006 kelésével és elemzésével felállítottam a mintahasználattal kapcsolatos téziseimet. E téziseket figyelembe véve kidolgoztam az SDP keretrendszer elméletét. Az internetes felméréssel párhuzamosan egy további, gyakorlati felmérést végeztem tanárokkal, fejlesztőkkel és tanulókkal a minta hasznosságára vonatkozóan. Az SDP-city keretrendszer egy példánya az SDP-city weblap: http://sdp-city.hu. A lap fejlesztése és az értékek felrakása folyamatban van. A következő pontokban ismertetem az első lépéseket és eredményeket.

3.2.

Szoftverfejlesztés – kísérleti tantárgy

A kutatás egyik indítéka a következő volt: a SZÁMALK-ban a 2001/2002-es, majd a 2002/2003-as tanévben szoftverfejlesztési tantárgyat indítottunk tanártársaimmal együtt, OKJ Számítástechnikai programozóknak, kísérleti jelleggel. A tanulók feladata SDP-k készítése volt, csapatmunkában. Már a tanfolyam megkezdése előtt sok időt töltöttem tanfolyami anyagok gyűjtésével; módszertanok és CASE eszközök tanulmányozásával; valamint szoftverminták, és minta SDP-k keresésével. Kész SDP-t nem találtam – sem szoftvermintákkal, sem anélkül. Tanártársaimmal hetente összegyűltünk, és ún. brainstormingot tartottunk egy-egy SDP elkészítése érdekében. Azonban az általunk, illetve a tanulók által készített SDP-ket azóta sem tudtuk összehasonlítani a „nagy szoftverfejlesztők” SDP-ivel. Ezt követően több módszerrel is tájékozódtam, hogy a szoftverfejlesztők, oktatók, tanulók és menedzserek − milyen mértékben ismerik és használják a szoftvermintákat. Arra is kíváncsi voltam, hogy aki használ szoftvermintát, milyet használ: sajátot, egy adott csoport belső mintáit, vagy a „mindenki által ismert”, klasszikus és publikus szoftvermintákat? − ismernek-e és felhasználnak-e mintaszerű SDP-ket. Több vonalon is végeztem kutatást hazai és nemzetközi viszonylatban.

3.3.

Interjúk

2003-ban készítettem egy előzetes felmérést Magyarországon a szoftverminták használatáról: megkérdeztem 32 szoftverfejlesztőt, oktatót, tanulót és menedzsert, hogy hallottak-e 30

3. A kutatás folyamata, első eredmények szoftvermintákról, illetve használják-e azokat. Összesen öten hallottak szoftvermintákról, ők is jellemzően a híres GOF féle tervezési mintákról [Gamma et al., 1995]. Mindössze egy fejlesztő használ tudatosan néhány mintát. Több kérdést tettem fel, íme néhány jellemző válasz: Fontos a minták használata? Használja valaki? − Szoftverfejlesztő: „A minták használata elengedhetetlen egy nagyobb rendszer fejlesztésénél, mivel ezek nagyban meghatározzák az időállóságát. Probléma viszont, hogy nem ismerek jól használható publikus mintagyűjteményt.” − Oktató: „Hallottam a Design Patterns-ről, de nekem nincs meg.” − Tanuló: „Mit jelent a minta pontosan?” − Menedzser: „Egyáltalán hol van olyan projekt, amiben használnak mintát? ... Az emberek általában nem is hallottak pattern-ekről.” Van a piacon jól dokumentált, mintaszerű szoftver? − Szoftverfejlesztő: „A dokumentáció a termék értékének 80-90%-át teszi ki. Aki kezébe kapja, egy csomó döntést készen kap, és így legalább olyan jó, vagy jobb szoftvert tud készíteni, mint aki az eredetit készítette. Én biztos nem fogom a termékeim anyagát kiadni senkinek.” − Oktató: „Én nem tudok róla. De nekem is jól jönne.” − Tanuló: „Igazából én még nem találkoztam szoftver-dokumentációval, csak forráskóddal.” − Menedzser: „Sajnos nincs ilyen. Pedig egyszerűen csak szemléletváltásra lenne szükség.” Hogy látja a szoftverfejlesztés oktatását? − Szoftverfejlesztő: „Nagyon rosszak a tapasztalataim. Mindenütt képeznek, illetve nem képeznek szoftverfejlesztőt. Igen sokszor maga a képzés neve is megfejthetetlen számomra... Az oktatási anyagokról: Egy-egy terület betanulása számomra mindig azt igényelte, hogy a piacon található összes könyvet vegyem meg. Ez sok bosszúságot okozott. Egy idő után már kizárólag a szoftverhez tartozó, általában gyári anyagokat vettem meg. Ma is ezt a technikát követjük. Az oktatási anyagokban elvesztettem a bizalmamat.” − Oktató: „Küzdünk.” 31

Angster Erzsébet: Doktori (PHD) értekezés, 2006 − Tanuló: „A szoftverfejlesztésről szóló könyvek majd kicsattannak az „okosságtól”, de a gyakorlatban nem tudom őket hasznosítani.” − Menedzser: „Hiányzik a gyakorlati (piacorientált) oktatás, a tanárok nem tudják bemutatni életszerű példákon az elméleti tudást.” 3.4.

Abakusz szoftverfejlesztő verseny

A Gábor Dénes főiskolán 2002-ben elindítottuk az Abakusz szoftverfejlesztő és tehetségkutató versenyt (szakmai vezetője Angster Erzsébet). A három éve folyó verseny szakmai elemzésében [Angster, 2005a] rámutatok: a versenyzők nem ismerik és nem használják a szoftvermintákat, és nem használnak mintaszerű tervezési és dokumentálási technikákat.

3.5.

Nemzetközi workshop a szoftverfejlesztés tanításáról

2003-ban a nemzetközi ECOOP konferencián egy workshop-ot tartottunk a szoftverfejlesztés tanításáról, Patterns in Teaching Software Development címmel [Angster et al., 2004a]. A munkamegbeszélésen készített felmérés alapján kiderült: a tanárok között a minta fogalma többnyire ismert, de csak kevesen és nagyon korlátozott mértékben tanítják. Az oktatók a fellelhető mintákkal és tananyagokkal nincsenek megelégedve, és egyetértenek abban, hogy a legfőbb baj, hogy a minták nem érhetők el könnyen, és hiányoznak a konkrét példák. A felmérés természetesen nem volt reprezentatív, mindössze figyelemfelkeltő. A workshop kiírásában a szervezők arra kérik a résztvevő oktatókat, hogy adjanak be egy kicsi, de konkrét projektet (dokumentációt és futó alkalmazást), mely a konkrét előadás alapjául szolgálhat. Sajnos a beérkezett anyagok közül egy sem tartalmazott konkrét projektet – mindegyik kivétel nélkül elméleti anyag volt, gyakorlati háttér nélkül. A workshop fő vitatémája az ok feltárása volt. A résztvevők megállapodtak abban, hogy egy szoftverfejlesztés oktatónak nem áll rendelkezésére kész, futó minta; elkészíteni pedig túl nagy energiabefektetés lenne. A résztvevők többsége nagyon hiányolta az SDP-ket. Aki nem hiányolta, arról kiderült, hogy főállásban szoftverfejlesztő. A workshop résztvevői közül sokan gondolták úgy, hogy nincs megfelelő minta-tárház és szoftverfejlesztési tananyag oktatási célra. Részletek a felmérés megjegyzéseiből: „A felsőoktatásban szinte egyáltalán nincs jó tananyag.”, „A baj az, hogy mindenki azt tanítja csak,

32

3. A kutatás folyamata, első eredmények amit tud.”, „A programjaimat önerőből fejlesztem, nem használom más mintáit.” „Mint mindenki, én is csak a GOF könyvet olvastam.”, „Az SDP-city weblap nagyon hasznos lenne, de valószínűleg sok pénzbe kerülne a fenntartása.”, „Az elérhető minták közt nem találok használható GUI mintákat.”, „Kevés az elemzési minta, és nincsenek rá példák.”.

3.6.

Az „Ördögi kör” felfedezése (1. tézis)

3.1. ábra. Az ördögi kör [Angster, 2004c]

1. tézis: Az ördögi kör felfedezése A kutatás első eredménye az „ördögi kör” felfedezése volt [Angster, 2004c]: − 1. lépés: A mintahasználat, a tervezés és a dokumentálás nem általános. A szoftverfejlesztés általános színvonala nem kielégítő. Ezért: − 2. lépés: A mintaszerű szoftverek (mintahasználattal, tervezéssel, dokumentációval) nagy értékek, ennélfogva azokat bizalmasan és titkosan kezelik. Ezért: − 3. lépés: Szinte egyáltalán nincs mintaszerű szoftver tanítási, illetve tanulási célra. Ezért:

33

Angster Erzsébet: Doktori (PHD) értekezés, 2006 − 4. lépés: A fejlesztők nem képesek elsajátítani a szükséges ismereteket a mintahasználathoz, tervezéshez és dokumentáláshoz. Ezért: − Vissza az 1. lépéshez, és a kör bezárult. Addig, amíg a jövő szoftverfejlesztői számára nincsenek mintaszerű szoftverek (mintákkal, tervezéssel és dokumentálással) tanulmányozás céljából, addig a jelenlegi szoftverfejlesztők nem fognak mintaszerű szoftvereket gyártani.

3.7.

A mintahasználattal kapcsolatos hipotézisek

A szoftverminták használata nyilvánvalóan javítaná a szoftverfejlesztés minőségét. Az előzetes felmérésekre alapozva azonban hipotéziseim a következők: 1.

A szoftverfejlesztők, oktatók, tanulók és menedzserek lényegében nem használnak mintákat, vagyis a mintahasználat nem terjed;

s ennek oka, hogy 2.

nincsenek meg a mintahasználat terjedésének tárgyi és személyi feltételei. A mintahasználat „kellékei”, mint a mintatárházak, az SDP-tárházak, az oktatás, a tananyag és a mintahasználat terjesztését befolyásoló személyek nagyon alacsony mértékben vannak jelen a szoftverfejlesztői körökben.

A kutatás egyik része a mintahasználatot befolyásoló tényezők összegyűjtése, másik része pedig annak felmérése, hogy a szoftverfejlesztői körök (fejlesztők, oktatók, tanulók és menedzserek) használnak-e mintákat, és hogy a szóban forgó tényezők milyen mértékben vannak jelen. Hipotéziseim nemzetközi viszonylatra is érvényesek; jelen kutatás a hazai szoftverfejlesztői körökre terjed ki.

A kutatás eredményeképpen létrehozom az SDP keretrendszert mint újítási modellt (lásd 10. fejezet), melynek elsődleges célja a mintahasználat terjedésének elősegítése, s ezzel a szoftverfejlesztés minőségének javítása. Az SDP keretrendszer tulajdonságait a felmérés eredményének megfelelően alakítom ki, vagyis jelen lesznek a mintahasználatot befolyásoló tényezők: mintatárház, SDP-tárház stb. Az SDP keretrendszer egy konkrét megvalósítása lesz az SDP-city weblap. 34

4. Felhasznált kutatások

4.

Felhasznált kutatások A kutatás elsődleges célja annak megállapítása, miért nem terjednek a minták, és mit

kellene tenni annak érdekében, hogy terjedjenek. Összegyűjtöm a mintahasználatot esetlegesen befolyásoló tényezőket, majd kérdőív segítségével felmérem és elemzem e tényezők konkrét értékeit. A terjedést befolyásoló tényezők meghatározásához és a kérdőív konkrét kérdéseinek összeállításához elsősorban a következő kutatásokat vettem figyelembe: − Az innováció terjedése [Rogers, 1995], − Egész termék [MooreGA, 1991], − Szoftverfejlesztési innováció [Attewell, 1992], − A fejlesztő bevonása és irányításérzékelése [Green et al., 1999], és − A minták terjedését befolyásoló tényezők vizsgálata [Manns, 2002]. 4.1.

Az innováció terjedése

Az innováció terjedésének (Diffusion Of Innovation, DOI) elméletét Rogers [1995] alapozta meg. Szerinte az innováció (újítás) egy adott befogadó egység által újnak érzékelt ötlet, gyakorlat vagy termék. A terjedési folyamat, diffúzió az a mód, ahogy az innovációt ismerő és használó szereplők, vagyis egy szociális rendszer tagjai az adott kommunikációs csatornák segítségével átadják azt más, az innovációt még nem ismerő szereplőknek a szociális rendszerben. A terjedés eredményeképpen az újítást egyre többen adoptálják, s ezzel az innováció terjed, hódítja a piacot. Rogers azt vizsgálja, mely faktorok befolyásolják egy innováció terjedését és elfogadását egy adott szociális rendszerben, közösségben. Tekintettel az alkalmazható területek sokoldalúságára, az utóbbi évtizedekben a DOI kutatás széles körben elterjedt, mára óriási irodalma van. Rogers az innováció terjedését befolyásoló tényezőket négy kategóriába sorolja (dőlt betűkkel jelzem a jelen kutatásban felhasznált tényezőket):

35

Angster Erzsébet: Doktori (PHD) értekezés, 2006 − Innováció: maga a terjesztendő dolog. Rogers szerint a terjedést elsősorban az innováció következő tulajdonságai határozzák meg: relatív előny, kompatibilitás, bonyolultság, kipróbálhatóság és megfigyelhetőség. − Kommunikációs csatornák: olyan eszközök, melyek segítségével az üzenetek eljuthatnak egy egyéntől egy másik egyénig. − Idő: Az időnek az innováció terjedésében három gyorsítási/lassítási tényezője van: az innováció-elhatározási folyamat; az innovatív szándék; valamint az elfogadás mértéke. − Szociális rendszer: A szociális rendszer tagjai vagy egységei hasonló problémákat szeretnének megoldani egy közös cél elérése érdekében. A szociális rendszernek van egy határa, melyen belül az innováció terjed. Az innováció terjedését befolyásolja a szociális szerkezet, a szociális normák, valamint a terjesztésben vállalt szerepkörök (az ilyen szerepkörrel rendelkező egyének jelenléte és tulajdonságai), mint az élharcos, a véleményvezető és a változási ügynök. Az innováció tulajdonságai (ahogyan azt a szociális rendszer tagjai észlelik/felfogják) meghatározzák az elfogadás mértékét. Az egyének sokkal gyorsabban fogadják el azokat az innovációkat, amelyek nagyobb relatív előnnyel rendelkeznek, kompatíbilisek, kevésbé bonyolultak stb., mint azokat az innovációkat, amelyek nem rendelkeznek ezekkel a tulajdonságokkal. A DOI tényezők többségét e kutatás is vizsgálja a szoftverminta terjedésének vizsgálatában. Moore és Benbasat [MorreGC et al., 1991] a DOI elméletét továbbfejlesztette. Az általuk készített modell Az innovációk érzékelt tulajdonságai (PCI, Percieved Characteristics of Innavation) néven vált ismertté. Az elmélet lényege, hogy elsősorban nem az innováció tényleges tulajdonságai a fontosak, hanem az, hogy a tulajdonságokat milyen mértékben észleli a használó. A PCI az innováció tulajdonságainak számát ötről nyolcra bővíti: a Rogers féle Megfigyelhetőség faktort kettébontja Láthatóság és Eredmény felmutathatósága faktorokra, és hozzáveszi az Arculat és Önkéntesség faktorokat. A minta használata egy innováció [Manns, 2002], és az SDP keretrendszer is innováció. Mindkettő újnak érzékelt ötlet, gyakorlat, illetve termék, befogadó egységük a szoftverfejlesztői közösség (fejlesztők, oktatók, tanulók és menedzserek). A mintahasználat terjedése az a folyamat, melyben egyre többen használnak, illetve készítenek mintákat. E kutatásban a mintahasználatot befolyásoló tényezők között jelen lesz a DOI elmélet összes innovációs tulajdonsága – más kutatásokat is figyelembe véve [MorreGC et al., 1991; 36

4. Felhasznált kutatások Green et al., 1999; Manns, 2002] – a Relatív előny Hasznavehetőség néven, a Bonyolultság Könnyű használat néven, a Megfigyelhetőség pedig kettébontva Láthatóság és Eredmény felmutathatósága néven. Az idő tényezők közül e dolgozat csak az Innovatív szándékkal foglalkozik – az Innováció-elhatározási folyamattal és az Elfogadás mértékével nem. A szociális rendszer mindhárom tényezője: Élharcos, Véleményvezető és Változási ügynök részt vesz a felmérésben. Az Arculat tulajdonsággal e kutatás nem foglalkozik, tekintve, hogy Manns [2002] felmérése szerint ez a tényező igen alacsony értékkel van jelen a mintát használók körében.

4.2.

Egész termék

Az egész termék (whole product) fogalmát G. A. Moore vezette be először [MooreGA, 1991]. Szerinte egy technológia lényegében két hullámban terjed el: az első hullámban a korai adoptálók, a másodikban a pragmatisták (a többség) adoptálják az újítást; s e két tábor között egy szakadék van. A pragmatisták (ők a többség) akkor kezdik el használni az újítást, amikor már minden letisztult körülötte, kevés benne a rizikó, kényelmes, és világosan látszik az eredmény felmutathatósága. Moore szerint a pragmatistának csak akkor lehet eladni az innovációt, ha az egy „egész termék”. Egy innováció, illetve termék pedig akkor lesz kereskedelmi értelemben érett, ún. egész termék, ha az már rendelkezik azokkal a másodlagos termékekkel és szolgáltatásokkal is, amelyekre a pragmatistáknak szüksége van. Enélkül a kiegészítők nélkül az innováció nem képes terjedni. Egy egész termék stabil és könnyű használni; tartozik hozzá oktatás, dokumentáció és támogatás (szupport), és ezeket könynyű elérni [MooreGA, 1991]. Az egész termék tulajdonságai három kategóriába sorolhatók [FowlerP, 1995; Manns, 2002]: − oktatás (training); − szabványok és eljárások (standards and procedures), vagy más néven bevezetett eljárás [Green et al., 1999]; − eszköztámogatás (tool support); ide tartoznak a fejlesztőeszközök és a különböző tárházak, gyűjtemények is. A potenciális adoptálókra tehát hatással lehet, hogy kapnak-e megfelelő oktatást és eszköztámogatást, valamint hogy a szervezet hangsúlyoz-e (esetleg kötelezővé tesz) bizonyos eljárásokat és szabványokat. Ezek a jelenségek természetesen összefüggésben lehetnek az innováció 37

Angster Erzsébet: Doktori (PHD) értekezés, 2006 bonyolultságával. Green et al. [1999] szerint egy szervezet minél jobban erőlteti a szabványok és struktúrák alkalmazását, az egyének annál elégedettebbek lesznek az újítás használatával. Azt állítja, hogy ez minden bizonnyal a lényeges tudáskorlát miatt van: minél bonyolultabb egy rendszer, annál inkább igényli a vezetést a rendszert használó egyén. Az egész termék elméletével sok szerző foglalkozott. Norman [1999] szerint a piacszerzés szempontjából is nagyon fontos, hogy a termék egyszerű, érthető, kényelmes és esztétikus, dokumentációja pedig rövid és lényegre törő legyen. Bernard Golden [2003] az Open Source technológia egész termékké alakításának módjáról ír. Mint mondja, már elegendően sok szervezet (a korai adoptálók) adoptálták a nyílt forráskódú technológiát, és eljött az ideje, hogy a pragmatisták is adoptálják azt. Sajnos azonban még hiányzik a technológia egész termék jellege, vagyis nincsenek meg a terjedéshez szükséges másodlagos termékek és szolgáltatások. A mintahasználat is csak akkor fog terjedni, ha az egész termékké válik. A többség nem fogja használni a mintákat, ha az rendkívüli erőfeszítéseket kíván. A szoftverminták egész termék változatával én még nem találkoztam. Kérdőív segítségével szeretném bebizonyítani: a minták használatának legnagyobb gátja, hogy hiányzik az oktatás, a dokumentáció (tananyagok, leírások, felhasználói és fejlesztői dokumentációk) és az eszköztámogatás (elsősorban a minta- és SDP-tárházak). A szabványok (mintasablonok) és a bevezetett eljárások mint például a pásztorolási (shepherding) folyamat [Harrison, 1999] lényegében megtalálhatók a minták területén – azonban ezeket csak szűk körben alkalmazzák. A kutatásban felállított modell következő tényezői figyelembe veszik az egész termék jellemzőit: Mintatárház, SDP-tárház, Oktatás, Tananyag, Bevezetett eljárás, Fórum.

4.3.

Szoftverfejlesztési innováció

Egy innovációt szoftver-eljárási innovációnak (Software Process Innovation, SPI) vagy szoftverfejlesztési innovációnak nevezünk, ha az szoftverfejlesztési célt szolgál, és lényegesen eltér az eddigi szoftverfejlesztési gyakorlatoktól. Az utóbbi néhány évtizedben rengeteg szoftverfejlesztési technika, módszertan és eszköz született a szoftverkrízis enyhítésére. Több kutató foglalkozott már azzal, hogyan lehet a szervezeteknél a szoftverfejlesztési technikákat mint szoftverfejlesztési innovációt sikeresen elterjeszteni. Sok ígéretes új eszköz és technika javította már a szoftverfejlesztést, de a legtöbbet vagy nem adoptálták széleskörűen, vagy hamar megbukott [Green et al., 2000]. 38

4. Felhasznált kutatások Az SPI elmélet azt vizsgálja, mely faktorok befolyásolják egy szoftver-eljárási innováció elterjedését. A DOI, illetve a PCI faktorait sok SPI kutatás átvette. Ismert szoftverfejlesztési innovációk és az azokról készült tanulmányok például: Workstations [MooreGC et al., 1991], OOP languages [Fichmann et al, 1997], CASE tools [Chau, 1996; Iivari, 1996], World Wide Web use [Agarwal, 1997], Personal Software Process [Green et al., 1999], Pattern use [Manns, 2002]. A mintahasználat és az SDP keretrendszer szoftverfejlesztési innovációk, hiszen azok a szoftverfejlesztést kívánják segíteni, és ehhez hasonló innováció, szoftverfejlesztési eljárás ezelőtt nem létezett. Mind a mintahasználat, mind az SDP keretrendszer esetén alkalmazhatók az SPI terjedésének vizsgálatánál használt faktorok. A szoftverfejlesztési innovációkra alapvetően jellemző a következő két dolog [Attewell, 1992, Fichman et al, 1997]: − Lényeges tudáskorlát (knowledge barrier): A szoftverfejlesztési innovációk természetüknél fogva meglehetősen bonyolultak. Az egyszerű innovációkkal ellentétben az SPI-k nincsenek „fekete dobozokba” csomagolva, ennélfogva nem lehet kevés tanulással könnyen adoptálni és használni őket. A szoftverfejlesztési innováció hatékony használatához széleskörű tudásra van szükség, mely komoly terhet jelent a potenciális befogadónak. A szoftverfejlesztési innovációk esetében a lényeges tudáskorlát miatt a terjedést erősen befolyásolják az olyan szociális tényezők, mint az oktatás és az egyének segítése. − Adoptálók kölcsönös függése (adopter interdependencies): Az egyén SPI adoptációja erősen függ a környezetében levő egyének adoptációjától. A legtöbb egyént nem a tudományos szakértők bizonyításai, hanem a közelében levő egyének rábeszélései befolyásolják [Rogers, 1995]. A mintahasználatot és az SDP keretrendszert mint SPI innovációt tehát erősen jellemzi a lényeges tudáskorlát és az adoptálók kölcsönös függése. Míg az adoptálók kölcsönös függése adott esetben gyorsíthatja a terjedést, a lényeges tudáskorlát erősen gátolhatja azt. E két tulajdonság miatt a legtöbb szerző alapvetően fontosnak tartja az oktatást az SPI terjedésében. Bonyolult technológiák esetén az egyének oktatása elsődleges szerepet játszhat a sikeres terjedésben [Attewell, 1992; Fichman et al., 1994]. A tudáskorlát jelenléte előtérbe helyezi az oktatás és mentorálás szükségességét [Manns, 2002].

39

Angster Erzsébet: Doktori (PHD) értekezés, 2006 Az adoptálók kölcsönös függése miatt lényeges, hogy az egyének között pozitív kommunikáció alakuljon ki. Ehhez szükség van egyrészt a jó kommunikációs csatornákra, másrészt olyan egyénekre, akik az innováció terjedésében jelentős szerepeket vállalnak. E kutatás a mintahasználat terjedését befolyásoló faktorok összeállításánál figyelembe veszi az SPI fenti tulajdonságait, és a faktorlistába felvesz az oktatással és az oktatás támogatásával kapcsolatos faktorokat: Mintatárház, SDP-tárház, Oktatás, Tananyag és Fórum.

4.4.

A fejlesztő bevonása és irányításérzékelése

Developer Involevement (a fejlesztő bevonása) • Adoption (elfogadás) • Adaptation (alkalmazás)

IT Diffusion Environment (IT terjedési környezet) • Degree of Novelty (újdonság foka) • Application Domain (alkalmazási terület) • Tool Support (eszköztámogatás) • Champion Support (élharcos támogatás) • Training (oktatás) • Voluntariness of Use (önkéntesség)

Perceived Control (irányításérzékelés) • Choice (választás) • Process (eljárás) • Predictability (megjósolhatóság)

Perceived IT Characteristics (érzékelt IT tulajdonságok) • Ease of Use (könnyű használat) • Usefulness (hasznavehetőség)

IT Diffusion Success (IT terjedési siker) • Use (használat) • Satisfaction (elégedettség)

Perceived Impacts (érzékelt hatások) • Quality (minőség) • Productivity (produktivitás)

4.1. ábra. Green kutatási modellje [Green et al., 1999]

Green et al. [1999], aki a szoftverfejlesztési technikák gyakorlatba való bevezetésének technikai és viselkedési kérdéseit vizsgálta, a Használó bevonása elméletét fejlesztette tovább. Green et al. szerint a szoftverfejlesztési problémák megoldásainak a technikai tényezők mellett humán tényezőket is tartalmazniuk kell. A szoftverfejlesztési technikák terjedéséről 40

4. Felhasznált kutatások szóló modelljében A fejlesztő bevonása (Developer Involvement) jelentős faktorként szerepel. Green et al. [1999] kimondja: nagyon fontos, hogy a fejlesztő úgy érezze, hogy ellenőrzi és befolyásolja a körülötte történő eseményeket. Pszichológiai tanulmányok kimutatták, hogy a legfontosabb szempont nem is a tényleges ellenőrzés, hanem az ellenőrzés érzékelése. Vagyis a fejlesztés sikeresebb, ha úgy érezzük, hogy urai vagyunk a helyzetnek, és nagyon fontos, hogy ez tudatosodjon bennünk a jobb eredmény érdekében. Green et al. egy kutatási modellt állított fel (4.1. ábra), amely azt vizsgálja, milyen összefüggések vannak a fejlesztőnek az IT elfogadási (adoptációs) és alkalmazási (adaptációs) folyamatába való bevonása, az IT tulajdonságai a terjedési környezetben, és az IT terjedési sikere között. Green et al. szerint a fejlesztő bevonása (az adoptációba és az adaptációba) és a terjedési környezet (újdonság foka, alkalmazási terület, eszköztámogatás, élharcos támogatás, oktatás és önkéntesség) úgy van hatással a terjedési sikerre, hogy közbeékelődik egy mediátor réteg: (1) a fejlesztő IT használat feletti irányításérzékelése (választás, eljárás, megjósolhatóság), (2) a fejlesztő által érzékelt IT tulajdonságok (könnyű használat és hasznavehetőség), és (3) a fejlesztő által érzékelt hatások (minőség és produktivitás). Green et al. eredményeit egy konkrét szoftverfejlesztési eljárásra, a PSP-re (Personal Software Process) is alkalmazta, de csak egy szűkített kutatási modellen – a szűkített modell tényezőit a 4.1. ábra dőlt betűsen mutatja. Green et al. kimutatta, hogy az IT terjedésének sikerességére direkt hatással van a fejlesztő bevonása, a terjedési környezetből pedig az oktatás (training) és az önkéntesség (voluntariness), és jelentős közvetítő szerepet játszik az irányításérzékelés (perceived control). Az irányításérzékelés egyik komponense, az eljárás (process) negatív hatású. Green et al. állítja: minél jobban úgy érzékelik a fejlesztők, hogy irányítják az eljárást, illetve a folyamatokat, annál kevésbé lesznek elégedettek a használattal; vagyis fordítva: minél jobban erőlteti egy cég a szabványokat és struktúrákat a PSP (Personal Software Process) bevezetésénél, annál elégedettebbek lesznek a fejlesztők a PSP használatával. A szoftverfejlesztési innovációkban az Eljárások és szabványok [MooreGA, 1991] kategóriát több szerző bevezetett eljárásnak nevezi [Fichmann et al, 1997; Manns, 2002]. Ilyen értelemben Green et al. szerint a Bevezetett eljárás pozitív hatással van a használatra. Jelen kutatás felveszi a mintahasználatot befolyásoló tényezők listájára a következő tényezőket: Újdonság foka, A fejlesztő bevonása, Tárház (eszköztámogatás), Élharcos, Oktatás, Bevezetett eljárás, Hasznavehetőség, Könnyű használat, Érzékelt minőség és Érzékelt produk-

41

Angster Erzsébet: Doktori (PHD) értekezés, 2006 tivitás. E tényezők közül az eszköztámogatás, az érzékelt minőség és az érzékelt produktivitás nincsenek benne Green et al. szűkített modelljén, vagyis az e tényezőkre gyűjtött adatokat ebben a tanulmányában nem analizálta, tekintettel az analízis bonyolultságára. Azonban ezek a tényezők más munkákban is jelentős hangsúlyt kapnak (eszköztámogatás: [MooreGA, 1991; Manns, 2002], érzékelt minőség és érzékelt produktivitás: [Iivari, 1996]). Az SDP keretrendszer erősen bevonja majd a szoftverfejlesztőt (a használót), hiszen a rendszert maguk a használók fogják feltölteni tartalommal, ők fogják elkészíteni a rendszer mintáit, SDP-it stb.

4.5.

A minták terjedését befolyásoló tényezők vizsgálata

Mary Lynn Manns doktori értekezésében [Manns, 2002] a szoftverminták adoptálását és terjedését vizsgálja egyének között és szervezetekben (4.2. ábra). Ph.D. dolgozatának címe: An Investigation Into Factors Affecting the Adoption and Diffusion of Software Patterns in Industry19. Manns kutatásának elsődleges célja annak megállapítása, hogy a már más kutatásokban is használt tényezőknek, mint relatív előny, kompatibilitás, könnyű használat, kipróbálhatóság, oktatás stb.) milyen hatása van a minta használatára. A dolgozat útmutatást ad azok számára, akik be szeretnék vezetni szervezetükben a minták használatát: mire kell odafigyelniük, mit kell tenniük ahhoz, hogy a bevezetés sikeres legyen. Manns kimutatta, hogy a szoftverminta használatot leginkább a következő tényezők befolyásolják: oktatás, láthatóság (a fejlesztő látja a másik fejlesztőt, hogy mintákat használ), véleményvezető (aki véleményével pozitívan befolyásolja a többi fejlesztőt), kompatibilitás (mennyire illeszkedik a fejlesztő eddigi munkájába), mintatárház, hasznavehetőség (mennyire érzi hasznosnak), eredmény felmutathatósága és kipróbálhatóság. Manns csak az összefüggéseket vizsgálja; nem vizsgálja a tényezők konkrét értékeit, vagyis azt, hogy a fejlesztők részt vesznek-e oktatásban, látható-e számukra a mintahasználat, van-e véleményvezetőjük, kompatibilis-e a mintahasználat eddigi munkájukkal, van-e elérhető mintatárházuk, hasznosnak vélik-e a mintahasználatot, fel tudnak-e mutatni eredményt, és ki tudják-e próbálni a minták használatát. Könnyű következtetni: ha a mintahasználatot befolyásoló tényezők értékei növekednének, akkor a mintahasználat is növekedne.

19

A szoftverminták iparban történő elfogadását és terjedését befolyásoló tényezők vizsgálata

42

4. Felhasznált kutatások

Potential Adopters’ Perceptions of Patterns’ Attributes (potenciális elfogadóknak a mintát érzékelő tulajdonságai) Relative Advantage (+) (relatív előny) Compatibility (+) (kompatibilitás) Ease Of Use (+) (könnyű használat) Trialability (+) (kipróbálhatóság) Result Demonstrability (+) (eredmény felmutathatósága) Visibility (+) (láthatóság) Image (+) (arculat) Voluntariness (-) (önkéntesség)

Potential Adopters’ Perceptions of Social System (potenciális elfogadóknak a szociális rendszert érzékelő tulajdonságai) Social influences (szociális hatás) Champion (+) (élharcos) Opinion Leader (+) (véleményvezető) Change Agent (+) (változási ügynök) Situational influences (helyzeti hatás) Training (+) (oktatás) Patterns Repository (+) (mintatárház) Negatív hatású lett a Installed Process (+) felmérésben. (bevezetett eljárás)

Pattern Use (mintahasználat) Use (használat) Use only in own work (használat saját munkában) Use in groups (használat csoportosan) Use by writing (használat írással)

Innovativeness of the Potential Adopter (potenciális elfogadók újdonsági foka) Innovativeness (+) (újdonság foka)

4.2. ábra. Manns kutatási modellje [Manns, 2002]

43

Angster Erzsébet: Doktori (PHD) értekezés, 2006 Manns kutatási eredményeit figyelembe veszem, és azokat a faktorokat, amelyek szerinte pozitívan befolyásolják a minta használatát én is felveszem a listára: Innovatív szándék, Mintatárház, Élharcos, Véleményvezető, Változási ügynök, Oktatás, Bevezetett eljárás, Hasznavehetőség, Könnyű hasznűlat, Kompatibilitás, Láthatóság, Eredmény felmutathatósága és Kipróbálhatóság. Mannstól átveszem a mintahasználat négy tényezőre bontását is: Használat, Használat saját munkában, Használat csoportosan, Használat mintaírással. Jelen kutatás a 4. fejezetben tárgyalt kutatásokat is figyelembe véve további tényezőket is vizsgál, amelyek befolyásolhatják mintahasználatot – ilyen a Tananyag, az SDP-tárház és a Fórum. Jelen kutatás továbbá azt is megvizsgálja, hogy a mintahasználatot befolyásoló tényezők milyen mértékben vannak jelen a szoftverfejlesztői közösségben.

44

5. A mintahasználatot befolyásoló tényezők

5.

A mintahasználatot befolyásoló tényezők

5.1.

A mintahasználatot befolyásoló tényezők modellje (2. tézis)

Felállítottam egy modellt (5.1. ábra), melyben összegyűjtöttem azokat a tényezőket (faktorokat, változókat), amelyek – az előző fejezetben ismertetett kutatásokat figyelembe véve, – feltételezhetően befolyásolják a mintahasználatot, vagyis a mintahasználat terjedését.

A mintahasználatot befolyásoló tényezők A mintahasználat érzékelt tulajdonságai A mintahasználat terjedési környezete B1. B2. B3. B4. B5. B6. B7. B8. B9. B10. B11. B12.

Újdonság foka (-) Innovatív szándék A fejlesztő bevonása Mintatárház SDP-tárház Élharcos Véleményvezető Változási ügynök Oktatás Tananyag Bevezetett eljárás Fórum

B13. B14. B15. B16. B17.

Hasznavehetőség Könnyű használat Kompatibilitás Láthatóság Eredmény felmutathatósága B18. Kipróbálhatóság

A mintahasználat érzékelt hatásai

Mintahasználat H1. Mintahasználat H2. Mintahasználat saját munkában H3. Mintahasználat csoportosan H4. Mintahasználat mintaírással

B19. Érzékelt minőség B20. Érzékelt produktivitás

5.1. ábra. A mintahasználatot befolyásoló tényezők modellje

45

Angster Erzsébet: Doktori (PHD) értekezés, 2006 Az ábra mutatja a tényezők főbb csoportjait és a közöttük levő várható hatások irányait. A tényezők nagy részét az előző fejezetben ismertetett kutatásokból vettem át, majd saját tényezőket is bevezettem. Az egyes tényezőket a fejezet részletesen is tárgyalja. A modellen a Hi tényezők a használat tényezői, míg a Bi tényezők a használatot befolyásoló tényezők. A mintahasználat módját Manns-hoz hasonlóan négy részre bontom: Mintahasználat általában, saját munkában, csoportosan és mintaírással. A befolyásoló tényezők: − Más kutatásokból átvett tényezők: Újdonság foka, Innovatív szándék, A fejlesztő bevonása, Mintatárház, Élharcos, Véleményvezető, Változási ügynök, Oktatás, Bevezetett eljárás, Hasznavehetőség, Könnyű használat, Kompatibilitás, Láthatóság, Eredmény felmutathatósága, Kipróbálhatóság, Érzékelt minőség, Érzékelt produktivitás. − Saját tényezők: SDP-tárház, Tananyag és Fórum. A modellben a mintahasználatot befolyásoló tényezőket Green et al. [1999] modelljére alapozva csoportosítottam. Green szerint meg kell különböztetni az innováció konkrét terjedési környezetét, és a használó által érzékelt tulajdonságokat és hatásokat. Ezek mindegyike hatással van az innováció használatára (terjedésére), de az érzékelések egyfajta mediátor szerepet is játszanak az innováció terjedésében: az innováció konkrét terjedési környezete hatással van az érzékelésre, amely viszont hatással van a használatra. A mintahasználatot befolyásoló tényezők nagy részét Manns is vizsgálja [Manns, 2002]. Manns célja azonban kizárólag a mintahasználatot befolyásoló tényezők meghatározása volt, a faktorok értékeinek egy szélesebb fejlesztői körben való vizsgálatára Manns nem tér ki. Kutatásom fontos eleme a mintahasználatot befolyásoló faktorok konkrét értékeinek vizsgálata minél szélesebb körben. Ha a mintahasználatot leginkább befolyásoló faktorok értékei abszolút értékben alacsonyak, akkor világos, hogy a minta használatát és ezzel mint technológia terjedését ezen értékek növelésével lehet befolyásolni. Vagyis ha például a minta használatát befolyásolja az oktatás, a tananyag, az SDP-tárház, és a minta terjesztésében résztvevő szereplők jelenléte, és ezzel egyidőben a felmérésben résztvevők ezen tényezők hiányát érzékelik, akkor a megoldás ezen tényezők értékeinek növelése. Kérdőív segítségével vizsgálom meg, hogy az egyes változók milyen mértékben vannak jelen a szoftverfejlesztői közösség különböző rétegeinél (fejlesztők, oktatók, tanulók és menedzserek).

46

5. A mintahasználatot befolyásoló tényezők Ezek a faktorok – a vizsgálati eredményüktől függően – szerepelni fognak az SDP keretrendszer tulajdonságai között.

5.2.

Az egyes tényezők bemutatása

A következőkben sorban bemutatom a kutatási modell összes tényezőjét, az 5.1. ábra szerint csoportosítva. Minden esetben megadom a kérdőívben feltett, a tényezővel kapcsolatos kérdéseket, illetve állításokat. Más kutatásokból átvett tényezők esetén lehetőség szerint átvettem az általuk készített felmérésben megfogalmazott kérdéseket (állításokat) is. Több esetben a kérdések számát csökkentettem, és/vagy értelemszerűen átfogalmaztam. Megadom a kérdések kérdőívbeli sorszámát is a könnyű azonosíthatóság érdekében. A kitöltő a válaszokat egy ún. Likert skálán adta meg (a válaszérték egy 1 és 7 közötti érték, lásd 6.1. pont). Bizonyos kérdések (állítások) negatív módon vannak megfogalmazva (ezeket a megfelelő pontokban jelzem); ilyen esetben a válaszértéket megfordítom (7 mínusz a válaszérték). Több kérdés esetén a tényező tényleges értéke a tényezőhöz tartozó válaszértékek átlaga.

5.3.

Mintahasználat

Az IT innováció terjedésének egyik kulcs mérése a használat [Rogers, 1995]. Sok olyan tanulmány született, melyben a szerző az IT terjedésének sikerét az IT használatával mérte, például Workstations [MooreGC et al., 1991], CASE tools [Iivari, 1996], Personal Software Process [Green et al., 1999], Pattern use [Manns, 2002]. A használat négy fajtáját Mannstól vettem át. H1. Mintahasználat H1 általános mintahasználatot jelent. Egy egyén használ mintát (H1), ha a következő három mód bármelyike szerint (H2, H3 vagy H4) használ mintát. H2. Mintahasználat saját munkában Egy egyén saját munkában használ mintát, ha munkájába beleépít mások által készített mintákat. Ha valaki csak H2 szerint használ mintát, vagyis másokkal nem működik együtt (H3) és nem is ír mintát (H4), akkor ő passzív mintahasználó.

47

Angster Erzsébet: Doktori (PHD) értekezés, 2006 H3. Mintahasználat csoportosan Egy egyén csoportosan használja a mintákat, ha a szervezetében (cégénél, iskolájában) másokkal együttműködve használja a mintákat. Csoportos használat esetén a résztvevők megvitatják a felhasználandó, illetve készítendő mintákat (például tervezési műhelymunkán vagy fórumon). H4. Mintahasználat mintaírással Az egyén nem csak „olvassa”, hanem mások számára ír is szoftvermintákat. Fontos megjegyezni: a minta egy probléma jól bevált megoldása, melyet már több ember, több alkalommal kipróbált (lásd 2.4. pont). A csak saját részre gyártott „minták” tehát nem minták.

A dolgozatban a használat mind a négy módját vizsgálni fogom (H2, H3 és H4 faktorok). Az első, Mintahasználat faktor a többi háromtól nyilvánvalóan függ, hiszen ez fogalmazza meg az általános használatot. A kérdőív összeállításánál lényegében Manns [2002] állításait vettem át: 12. Használok mintákat. 13. Használok mintákat, de csak a saját munkámban. 14. Használok mintákat cégemben (iskolámban) másokkal együtt, tervezési műhelymunkán vagy más csapatmunkában. 15. Írtam már mintákat cégemnek, illetve valamilyen mintatárház részére.

Kiegészítésképpen felteszek konkrét kérdéseket is, melyekből következtetni lehet a tényleges mintahasználatra: 16. Hány minta tárházat használ? 17. Adja meg az Ön által használt fontosabb mintatárházakat! 18. Próbálja megbecsülni, hogy egy évre vetítve: hány munkanapot tölt el mintakereséssel, megértéssel vagy készítéssel; hány munkanapot takarít meg kész minták használatával.

5.4.

A mintahasználat terjedési környezete

B1. Újdonság foka (Degree of Novelty) Az újdonság foka annak mértéke, hogy az innováció megtanulása és használata mennyire jelent új tapasztalatot a használónak. Green A szoftverfejlesztők irányításérzékelése, és hatása az információtechnológia sikeres terjedésére című tanulmányában kimutatta, hogy az újdon-

48

5. A mintahasználatot befolyásoló tényezők ság foka direkt hatással van az IT terjedésének sikerességére [Green et al., 1999]. Chau [1996] szerint az újdonság foka a jelenlegi és az új technika által megkívánt gyakorlottság közötti különbség. Chau és Green határozott negatív korrelációt találtak az újdonság foka és az IT elfogadása között. A kérdőív összeállításánál figyelembe vettem Green et al. [1999] állításait: 19. A szoftverminta-használat mint technológia nem ismerős számomra. 20. Tisztában vagyok a mintákkal kapcsolatos elérhető nemzetközi irodalmakkal. Tudom, hol kell keresnem az analízis mintákat, architekturális mintákat, tervezési mintákat stb. 21. Cégemnél (iskolámban) a fejlesztők általában tisztában vannak a minta fogalmával, használhatóságával és a mintákkal kapcsolatos elérhető forrásokkal.

A 20. és a 21. állítás negatív, vagyis a tényező értékének számításánál ezen válaszértékek inverzét kell venni. B2. Innovatív szándék (Innovativeness) Az innovatív szándék az innováció elfogadásának egy gyorsítási/lassítási tényezője [Rogers, 1995]. Az innovatív szándék annak mértéke, hogy az egyén milyen hamar adoptál egy innovációt a többiekhez képest (az egyénnek információra és rábeszélésre van szüksége ahhoz, hogy egy innovációt elfogadjon). Egy egyén innovatív szándéka szerint lehet innovátor, korai befogadó, a korai többséghez tartozó, a késői többséghez tartozó, illetve elmaradozó. Az innovátorok általában szeretik az új dolgokat kipróbálni és használni. Az innovatív szándék alapvetően fontos egy innováció terjedésének sikerességéhez. Ha egy közösségben túl sok a pragmatista, illetve konzervatív gondolkodású egyén, akkor az innováció sokkal lassabban képes terjedni. Manns [2002] kimutatta, hogy az innovatív szándék pozitív hatással van a minta használatára. Azt azonban nem mérte fel, hogy a szoftverfejlesztők többsége innovatív-e. A kérdőív összeállításánál figyelembe vettem Manns [2002] kérdéseit: 22. Akkor használok majd én is szoftvermintákat, ha már sokan használják. Első használóként túl nagy az idő és energiaráfordítás.

23. Én általában szeretem az új dolgokat kipróbálni és használni. A 22. állítás negatív, vagyis a tényező értékének számításánál ezen válaszérték inverzét kell venni.

49

Angster Erzsébet: Doktori (PHD) értekezés, 2006 B3. A fejlesztő bevonása (Developer Involvement) Az egyén (használó) szoftverfejlesztési innovációba való bevonása azt jelenti: az egyén úgy érzi, hogy ellenőrzi és befolyásolja a körülötte történő eseményeket. Green et al. [1999] szerint a fejlesztő bevonása a szoftverfejlesztési technika implementációs eljárásába (előbb az adoptálásba, majd az adaptálásba) pozitív hatással van a szoftverfejlesztési technika használatára. Green ezt a PSP használatára be is bizonyította. A mintahasználat esetén a fejlesztő bevonása azt jelenti, hogy a fejlesztő részt vesz a mintatárház kialakításában úgy, hogy ahhoz értéket ad. Tudomásom szerint még nem mérte fel senki, hogy a cégek mennyire vonják be a fejlesztőket a mintatárházak készítésébe. Van azonban egy fórum, amely lehetőséget ad a fejlesztőknek publikus minták készítésére: a Pattern Languages of Programming [PLoP] konferenciák szervezett keretet adnak az ellenőrzött (pásztorolt) minták készítésére. Ez a platform azonban csak egy aránylag szűk kört érint; a nagy fejlesztői tömegeket nem mozgatja meg. E kutatás felméri, hogy a fejlesztőket mennyire vonják be a mintahasználatba: van-e beleszólásuk abba, hogy használjanak-e szoftvermintákat; mennyire vesznek részt a minták koncepcionális kialakításában; van-e olyan mintatárház, amelyhez ők is hozzátehetnek értéket. A kérdőív összeállításánál figyelembe vettem Green et al. [1999] kérdéseit: 24. Cégemnél (iskolámban) beleszólásom van abba, hogy használjunk-e szoftvermintákat. 25. Cégemnél (iskolámban) részt veszek a mintahasználat koncepcionális kialakításában. 26. Cégemnél (iskolámban) van olyan mintatárház, amelyhez én is hozzátehetek értéket.

B4. Mintatárház (Patterns Repository) A mintatárház egy mintákat, illetve mintacsomagokat tartalmazó gyűjtemény. A szoftverfejlesztő mintatárházból veszi ki az adott feladat megoldásához szükséges mintát. A mintatárház tényező azt fejezi ki, hogy a mintát használó egyénnek rendelkezésére áll-e mintatárház. Manns [2002] a Mintahasználatról szóló tanulmányában – elődeire is hivatkozva – a Mintatárházat a minta eszköztámogatásának tekinti. Az eszköztámogatás az Egész termék elmélet egy igen fontos eleme [MooreGA, 1991]. Holloway et al. [1996] szerint a fejlesztést támogató eszközök hiánya teljesen meggátolhatja a formális fejlesztési módszertan terjedését. Fayad et al. [1996] azt állítja, hogy a megfelelő támogató eszközök lehetővé teszik, hogy a fejlesztők a lényegre koncentrálhassanak. Green et al. [1999] tanulmányában a Tool Support az IT terjedés környezetének egyik fontos tényezője. 50

5. A mintahasználatot befolyásoló tényezők Manns [2002] kimutatta, hogy a Mintatárház pozitív hatással van a minta használatára. Azt azonban nem mérte fel, hogy van-e elegendő szoftverminta tárház a piacon és az oktatásban. Feltételezésem szerint nincsenek megfelelő mintatárházak, különösen oktatási célra. A fellelhető minták nem fedik le az SDP-k fejlesztésekor felmerülő problémákat. A kérdőív összeállításánál figyelembe vettem Manns [2002] egyetlen kérdését, s azt kiegészítettem két további kérdéssel. 27. Cégem (iskolám) rendelkezik egy szoftvermintatárházzal, amely hasznos számomra. 28. Elegendő szoftverminta található az Inteneten és a publikus könyvekben is, azok jól össze vannak szedve, könnyen elérhetők és kereshetők. 29. Jól tudok dolgozni az általam elérhető szoftvermintákkal.

B5. SDP-tárház (SDP Repository) Az SDP egy jól dokumentált, futó alkalmazás [Angster, 2004c]; a szoftverfejlesztés elméletének gyakorlati terméke. Az SDP-tárház egy SDP-ket tartalmazó gyűjtemény. Az SDP-tárház tényező azt fejezi ki, hogy az egyénnek (a mintát használónak) rendelkezésére áll-e SDP-tárház. Az elmélet sokkal érthetőbb, ha van mögötte futó alkalmazás – erre több szerző is felhívja a figyelmet [The Software Patterns Criteria, 1998; Schneider et al. 1999; Fowler, 2003b]. A szoftverminták minőségi ismérvei [The Software Patterns Criteria, 1998] között szerepel az Alapos megoldás és a Gyakorlati visszajelzés. Manns [2002] szerint a minta kipróbálhatósága és az eredmény felmutathatósága pozitív hatással van a minta használatára. Green et al. [1999] tanulmányában azt állítja, hogy az IT terjedés környezetének egyik fontos tényezője az Alkalmazási terület (Application domain): „Fontos, hogy a szoftverfejlesztési innováció alkalmazási területe a gyakorlatban konzisztens legyen azzal az alkalmazási területtel, amelyet a kutatás és fejlesztés során használtak.” Ehhez azonban a minta íróinak közre kellene bocsátaniuk azokat a futó alkalmazásokat, amelyekből a mintát vették. Holloway et al. [1996] több támogatást kér a kutatóktól azokhoz a modellekhez, amelyek alkalmazási területe kritikus a gyakorlatban. Ehhez képest nincs a piacon szinte egyetlen mintaszerű SDP sem [Angster, 2004c]. Green a felállított kutatási modelljéből csak egy részmodellt vizsgál meg, melyben az Application domain nem szerepel. Jelen kutatás ezt a fontos tényezőt beveszi a kutatási modelljébe. Mivel a minta alkalmazási területe a szoftverfejlesztés

51

Angster Erzsébet: Doktori (PHD) értekezés, 2006 és azon keresztül a kész szoftverek, a kutatás az SDP-tárházakat vizsgálja mint alkalmazási területet. Az SDP-tárház saját változó. Tudomásom szerint eddig egyetlen kutató sem vizsgálta az SDP-k jelenlétének hatását a mintahasználatra, valamint az SDP-k konkrét jelenlétét és elérhetőségeit. Feltételezésem szerint nincsenek megfelelő SDP-tárházak sem a fellelhető mintákhoz, sem másképp. Így a minták nem mutathatók be és nem próbálhatók ki. Konkrét példák lényegében csak az implementáció területéről vannak (nyílt forráskódok, komponensek). A felmérésben megvizsgálom, hogy mennyire állnak a fejlesztők rendelkezésére SDP-tárházak. A kérdőív összeállításánál nem támaszkodhattam elődökre. Az állítások a következők: 30. Cégem (iskolám) rendelkezik egy SDP-tárházzal, amely hasznos számomra. 31. Cégemnél (iskolámnál) vannak korrekt módon elkészített és dokumentált minta SDP-k, melyek jelentős segítséget adnak az újoncoknak az SDP készítésében. 32. Elegendő SDP található az Inteneten és a publikus könyvekben is, azok jól össze vannak szedve, könnyen elérhetők és kereshetők. 33. Én még nem is találkoztam korrekt, teljes SDP-vel, melyet használni tudnék a fejlesztés során.

A 33. állítás negatív, vagyis a tényező értékének számításánál ezen válaszérték inverzét kell venni. B6. Élharcos (Champion) Az élharcos olyan menedzser, aki személyes ráhatással aktívan és erőteljesen támogatja, előmozdítja, reklámozza az innováció használatát, és hárítja a megvalósítás esetleges akadályait, biztosítja a szükséges erőforrásokat és utat mutat. Az élharcosnak nincs igazán hitele a hozzáértésben, annál nagyobb a hihetőségben. Az élharcos az innováció szociális környezetében van jelen, és befolyásolja az innováció terjedésének mértékét. [Rogers, 1995]. A DOI elméletében a vállalt szerepkörök (élharcos, véleményvezető és változási ügynök) a szociális rendszer része. Manns [2002] mintájára én is megvizsgálom mindhárom szerepkört. A szerepkörökön kívül a szociális rendszer része még a szociális szerkezet és a szociális normák, de ezeket e felmérés Mannshoz hasonlóan nem vizsgálja, azokat adottnak tekinti a szoftverfejlesztői közösség körében. Az élharcos jelenléte pozitív hatással van a PSP használatára [Green et al., 1999], illeve a minta használatára [Manns, 2002]. Azt azonban tudomásom szerint nem vizsgálta meg senki, hogy a szoftverfejlesztői körökben általában jelen van-e a mintahasználat élharcosa.

52

5. A mintahasználatot befolyásoló tényezők Ennél a változónál Manns [2002] kérdéseit tettem fel (a tanulókat is megcélozva), de ehhez hasonló kérdéseket tesz fel Green et al. [1999] is: 34. Cégemnél (iskolámban) a vezetőség támogatja a minták használatát. 35. A főnököm (tanárom) pozitív hatással van rám a minták használatában.

B7. Véleményvezető (Opinion Leader) A véleményvezető olyan, a társaival egyenrangú személy, aki véleményével erős hatást gyakorol társaira, s ezzel segíti őket a döntésben. A véleményvezetőt társai becsülik és elfogadják. A véleményvezető az innováció szociális környezetében van jelen, és befolyásolja az innováció terjedésének mértékét. A véleményvezetőhöz jut el először még a nyilvánosnak szánt információ is, a társadalom többi tagjához csak ezután. [Rogers, 1995] Manns [2002] kimutatta, hogy a véleményvezető pozitív hatással van a minta használatára. Azt azonban nem mérte fel, hogy a mintahasználattal kapcsolatban jelen van-e a véleményvezetői szerepkör a szoftverfejlesztői körökben. Ennél a változónál Manns [2002] kérdéseit tettem fel (a tanulókat is megcélozva): 36. Munkatársaim (tanulótársaim) használnak mintákat. 37. Munkatársaim (tanulótársaim) pozitív hatással vannak rám a szoftverminták használatában.

B8. Változási ügynök (Change Agent) A változási ügynök az innováció szociális környezetében van jelen, és befolyásolja az innováció terjedésének mértékét [Rogers, 1995]. A változási ügynök pozitívan befolyásolja az innovációs döntéseket a szociális rendszeren és a változási ügynökségeken (például főnökségen) keresztül. A változási ügynök úgy képes befolyásolni az adoptálókat, ahogyan az a változást hozó képviselet (vezetőség) számára előnyös. A változási ügynök a megfelelő helyeken lobbizik. „Még a legteljesebb termékcsomag esetén sem nélkülözhetők a kompetens változási ügynökök ...” [Fowler, 1993]. Manns [2002] kimutatta, hogy a változási ügynök jelenléte pozitív hatással van a minta használatára. Azt azonban nem mérte fel, hogy a mintahasználattal kapcsolatban jelen van-e a változási ügynök szerepkör a szoftverfejlesztői körökben. Ennél a változónál Manns [2002] kérdéseit tettem fel (a tanulókat is megcélozva): 38. Cégemnél (iskolámban) van egy (vagy több) ember, aki felelős a minták bevezetéséért és a mintákkal kapcsolatos információ szolgáltatásáért.

53

Angster Erzsébet: Doktori (PHD) értekezés, 2006 39. Cégemnél (iskolámban) pozitív hatással van rám egy (vagy több) ember, aki felelős a minták bevezetéséért és a mintákkal kapcsolatos információ szolgáltatásáért.

B9. Oktatás (Training) Az oktatás tényező azt fejezi ki, hogy az egyénnek rendelkezésére áll-e mintahasználattal kapcsolatos oktatás. A szoftverminták minőségi ismérvei [The Software Patterns Criteria, 1998] között szerepel a Tanítás: a szoftvermintának tartalmaznia kell mind megoldási, mind tanítási elemeket. A tanítási elemek adják meg a „miért?” kérdésekre a választ, ésszerű magyarázatokkal. Gibbs [1994] szerint a szoftveripar jelentősen el van maradva az információs társadalom elvárásaihoz képest. Mint mondja, a legnagyobb probléma a szoftverfejlesztők szaktudásában és a minőségi oktatás hiányában van. Az SPI-kre jellemző a lényeges tudáskorlát. Az egyszerű innovációkhoz képest a szoftverfejlesztési innováció nagyon komoly aktuális és háttértudást feltételez [Attewell, 1992; Fichman, 1997]. Green et al. [2000] szerint az oktatás elérhetősége és hatékonysága egy szoftverfejlesztési innováció terjedésének kritikus tényezői. Booch [1994] felhívja a figyelmet arra, hogy a fejlesztők oktatása és motiválása a vezetőség felelőssége. Az oktatásban fontos szerepet játszanak az oktatás körülményei és az időpont megválasztása is: egy innováció bevezetése és oktatása egy ún. törésponton a leghatékonyabb, amikor az egyén vagy a csoport két munka között van [Fayad, 1996]. Az oktatás az Egész termék elmélet hangsúlyos eleme. FowlerP et al., [1993] ezt írja: „Egy új termék adoptálásánál az egész termék koncepciója kritikus: a technológia mellett jelen kell lennie a kiegészítő elemeknek, mint tanfolyamok, ügyféltámogatás, felhasználói kézikönyvek – mindazon dolgoknak, melyekre a használónak szüksége van.” Az oktatást, mint az IT terjedésének egyik befolyásoló tényezőjét több más, szoftverfejlesztési innovációval kapcsolatos kutatás is tartalmazza [Fayad et al., 1996; Green et al., 1999; Manns, 2002]. Manns kimutatta, hogy az oktatás pozitív hatással van a minta használatára. Manns szerepjátékos modelljében a fejlesztők az oktatást tartják a legfontosabbnak. Tudomásom szerint eddig még senki nem mérte fel, hogy a szoftverfejlesztői körökben milyen mértékben van jelen a mintahasználattal kapcsolatos oktatás. A kérdőív összeállításánál figyelembe vettem Manns [2002] és Green et al. [1999] kérdéseit:

54

5. A mintahasználatot befolyásoló tényezők 40. Cégem (iskolám) gondoskodott arról, hogy részt vegyek a szoftverminták hatékony használatához szükséges oktatásokon. 41. Meg vagyok elégedve a mintákkal kapcsolatos oktatások minőségével a cégemnél (iskolámnál). 42. Meg vagyok elégedve a mintákkal kapcsolatos hazai tanfolyami választékkal. 43. Megvan a lehetőségem arra, hogy részt vegyek olyan oktatáson, amely alapján el tudok készíteni korrekt SDP-ket.

B10. Tananyag (Teaching material) A tananyag tényező azt fejezi ki, hogy az egyénnek rendelkezésére állnak-e mintahasználattal kapcsolatos tananyagok. Több szerző hangsúlyozza az oktatás jelentőségét a szoftverfejlesztési eljárás terjedésében. Tudomásom szerint azonban a szerzők nem vizsgálják a tananyag jelenlétét. Pedig a széleskörűen hivatkozott Egész termékhez az oktatáson kívül dokumentáció is tartozik, amit könnyű elérni [MooreGA, 1991]. A tananyag saját változó. Tudomásom szerint mások még nem vizsgálták a tananyagot, mint a szoftverfejlesztési innováció terjedését befolyásoló tényezőt. Pedig feltételezésem szerint a szoftverfejlesztéssel és mintahasználattal kapcsolatos tananyagok nem teljesek: nem létezik olyan tananyag (sorozat), amely elsajátítása után elvárható lenne egy egyszerűbb SDP elkészítése, legalább iskolai szinten. A kérdőív összeállításánál nem támaszkodhattam mások kutatásaira. Az állítások a következők: 44. Rendelkezésemre áll megfelelő mennyiségű és minőségű tananyag, amiből megtanulhatom a minták használatát. 45. Rendelkezésemre áll megfelelő mennyiségű és minőségű tananyag, amely alapján el tudok készíteni konkrét és korrekt SDP-ket. 46. Az általam ismert tananyagok túlságosan absztraktak, nem elég gyakorlatiasak. 47. Az általam ismert tananyagok elegendően átfogóak, összefogják a szoftverfejlesztés részterületeit.

A 46. állítás negatív, vagyis a tényező értékének számításánál ezen válaszérték inverzét kell venni.

55

Angster Erzsébet: Doktori (PHD) értekezés, 2006 B11. Bevezetett eljárás (Installed Process) A bevezetett eljárás tényező azt fejezi ki, hogy az innováció bevezetésénél és alkalmazásánál a használónak mennyire kell megadott szabványok és eljárások szerint cselekednie, vannak-e sablonok, használati módszerek. [Green et al., 1999] Az egész termék modell harmadik kategóriája az Eljárások és szabványok [MooreGA, 1991]. A szoftverfejlesztési innovációkban ezt a kategóriát több szerző bevezetett eljárásnak nevezi [Fichmann et al, 1997; Manns, 2002]. Green et al. [1999] kutatásában ez a kategória a folyamatok érzékelt irányításaként jelentkezik, és állítja: minél jobban erőlteti egy cég a szabványokat és struktúrákat a PSP (Personal Software Process) bevezetésénél, annál elégedettebbek lesznek a fejlesztők a PSP használatával. Véleménye szerint ez a szoftverfejlesztés bonyolultságával, lényeges tudáskorlátjával magyarázható. A szoftverfejlesztési eljárások esetén a szabványok és eljárások bevezetése jelentős mértékben segítheti a fejlesztőt az adott innovációban való tájékozódásban, s ezzel jelentős mértékben növekedhet az elégedettség és a használat. Bevezett eljárás szükséges például a tervezéshez, a dokumentáláshoz, az újrahasználáshoz és a mintahasználathoz is. Fichmann et al. [1997] állítja, hogy a szoftverfejlesztési projektekben a kód újrahasználásának effektív kiaknázásához egy szervezetnek többre van szüksége, mint csupán az újrahasználható elemekre; szükség van eljárásokra és szabványokra is, melyek segítségével hatékonyan lehet ellenőrizni a feladatokat, a szerepköröket és a technikákat! Manns kimutatása szerint a bevezetett eljárás negatív hatással van a minta használatára. Fontos azonban, hogy Manns kizárólag gyakorlott szoftverfejlesztőket és mintahasználókat kérdezett meg. Tudomásom szerint még senki nem mérte fel, hogy a szabványok és eljárások milyen mértékben vannak jelen a szoftverfejlesztői szakmában. A minták szakmai koordinálása, az ún. pásztorkodási (shepherding) folyamat [Hillside, 2003] bevezetett eljárás. A szoftverminták minőségi ismérvei [The Software Patterns Criteria, 1998] között szerepel a Bírálat: „A szoftvermintát minősített szakemberek bírálják és elfogadják. A bírálat alapján a szerző javítja, átírja a mintát. Erősen ajánlott, hogy a mintát minél nagyobb csoport ellenőrizze és kommentálja.” A bíráló figyelembe veszi a minta minőségi kritériumait, mint hármas szabály, név, dokumentáció. A kérdőív összeállításánál figyelembe vettem Manns [2002] kérdéseit: 48. Cégemnél (iskolámban) a mintahasználat a szoftverfejlesztési eljárásainknak szerves része.

56

5. A mintahasználatot befolyásoló tényezők 49. Cégemnél (iskolámban) egy meghatározott eljárás szerint használjuk a mintákat. 50. Cégemnél (iskolámban) a mintákat egy adott sablon szerint kell elkészíteni.

B12. Fórum A fórum tényező azt fejezi ki, hogy a használónak milyen lehetőségei vannak a mintahasználattal kapcsolatos eszmecserére; mennyire tudja mások véleményeit követni, saját véleményének hangot adni, kérdéseit feltenni és azokra választ kapni. Az Egész termék elmélet [MoorGA, 1991] kimondja, hogy egy termék csak akkor lehet kereskedelmi értelemben egész, ha tartozik hozzá oktatás, dokumentáció és támogatás. A használó támogatásának egy formája a fórum. Manns [2002] mintanyelvében több fórumról szóló mintát is meghatározott. Ilyen például az e-Forum: „Hozzál létre hirdetőtáblát, terjesztési listát vagy levelezési listát azok számára, akik többet szeretnének hallani a minta használatáról!”; az Ask for help: „Mivel a minták bevezetése nagy munka, keressél erőforrásokat és embereket a munka elvégzéséhez körülötted vagy egy e-Fórumon!”; vagy a Workshop as Teacher: „Csinálj a tanulóknak mintaíró műhelymunkát, hogy tanulhassanak egymás mintáiból!” A fórum saját változó, tudomásom szerint a mintahasználatra tett hatását más kutató még nem mérte. A kérdőív összeállításánál nem támaszkodtam mások kutatásaira. Az állítások a következők: 51. Tagja vagyok egy levelezőfórumnak, ahol a mintákkal kapcsolatosan tájékozódni szoktam, és ahol kérdéseimre választ kapok. 52. Tagja vagyok egy olyan fórumnak (szervezetnek/klubnak), ahol az emberek használnak mintákat, és ahol a mintákkal kapcsolatos kérdéseimet megvitathatom.

5.5.

A mintahasználat érzékelt tulajdonságai

B13. Hasznavehetőség (Usefulness) A hasznavehetőség azt fejezi ki, hogy a potenciális adoptáló (jelen esetben a minta használója) úgy érzi-e, hogy az innováció használatával jobb lesz-e a helyzete, mint ami eddig volt. Ha nem, akkor az innováció nem fog elterjedni. Az objektív előny itt nem sokat számít; az a döntő, hogy az egyén hasznosnak, előnyösnek tartja-e az innovációt. Minél nagyobb az érzé-

57

Angster Erzsébet: Doktori (PHD) értekezés, 2006 kelt relatív előny az egyén számára, annál nagyobb az elfogadás mértéke. [Rogers, 1995, MooreGC et al, 1991]. A DOI elméletben a hasznavehetőség relatív előny elnevezéssel szerepel. A relatív előny egy a három faktor közül (relatív előny, kompatibilitás és bonyolultság), amely gyakorlatilag minden innováció-adoptációs vizsgálatban szerepel [Tornatzky, 1982]. Jelen felmérés vizsgálja, hogy a minta használata mennyire hasznos; milyen mértékben jár relatív előnyökkel a szoftverfejlesztő számára. Manns kimutatta, hogy a hasznavehetőség pozitív hatással van a minta használatára. Azt azonban nem mérte fel, hogy a mintahasználat hasznavehetőségének érzékelése milyen mértékben van jelen a szoftverfejlesztői szakmában. A kérdőív összeállításánál figyelembe vettem Manns [2002] és Green et al. [1999] kérdéseit: 53. A minták használata hasznos számomra. 54. A minták használatával előnybe kerülök azokkal szemben, akik nem használnak mintákat. 55. A minták használatával elvesztem kreativitásomat.

A 55. állítás negatív, vagyis a tényező értékének számításánál ezen válaszérték inverzét kell venni. B14. Könnyű használat (Ease of Use) A könnyű használat azt fejezi ki, hogy mennyire egyszerű az innováció megértése, használata az adoptáló számára. Az emberek sokkal gyorsabban elfogadják azokat az innovációkat, amelyeket könnyű megérteni és használni, mint azokat, amelyekhez sok tanulás és gyakorlás szükséges [Rogers, 1995; MooreGC, 1991]. A DOI elméletben a könnyű használat bonyolultság néven szerepel. A könnyű használat egy a három faktor közül (relatív előny, kompatibilitás és bonyolultság), amely gyakorlatilag minden innováció-adoptációs vizsgálatban szerepel [Tornatzky, 1982]. Manns kimutatta, hogy a Könnyű használat pozitív hatással van a minta használatára. Azt azonban nem vizsgálta, hogy a mintahasználat könnyűségének érzékelése milyen mértékben van jelen a szoftverfejlesztői szakmában. A kérdőív összeállításánál figyelembe vettem Manns [2002] és Green et al. [1999] kérdéseit:

58

5. A mintahasználatot befolyásoló tényezők 56. Könnyen váltam gyakorlott mintahasználóvá. 57. Jobban szeretem magam megoldani a fejlesztési feladatokat. Más mintáinak használata nekem komoly szellemi erőfeszítést igényelne. 58. Sokkal könnyebb a szoftver fejlesztése, ha használhatok kész mintákat.

A 57. állítás negatív, vagyis a tényező értékének számításánál ezen válaszérték inverzét kell venni. B15. Kompatibilitás (Compatibility) A kompatibilitás azt fejezi ki, hogy mennyire tudja az adoptáló összeegyeztetni az innovációt a többi dolgaival – hogy fog illeszkedni a már létező értékeihez, tapasztalataihoz és jelenlegi elvárásaihoz. Ha az emberek úgy érzik, hogy az innováció meg fogja változtatni körülményeiket, akkor ellenállóvá válnak az innovációval szemben. Egy inkompatibilis innováció elfogadása feltételezi egy másik, megelőző innováció elfogadását, amely lelassítja a befogadást [Rogers, 1995]. A kompatibilitás egy a három faktor közül (relatív előny, kompatibilitás és bonyolultság), amely gyakorlatilag minden innováció-adoptációs vizsgálatban szerepel [Tornatzky, 1982]. Több szerző gyakorlati kompatibilitást említ, ami azt jelenti, hogy az innováció mennyire illeszkedik az egyén munkájába, munkastílusába, illetve az egyén hogyan érzékeli ezt [MooreGC et al., 1991]. Jelen dolgozat is ilyen értelmezést ad a kompatibilitásnak. Manns kimutatta, hogy a kompatibilitás pozitív hatással van a minta használatára. Azt azonban nem vizsgálta, hogy a mintahasználat kompatibilitásának érzékelése milyen mértékben van jelen a szoftverfejlesztői szakmában. A kérdőív összeállításánál figyelembe vettem Manns [2002] kérdéseit: 59. A minták használata kompatibilis (összeegyeztethető) az egyéb szoftverfejlesztési módszereimmel. 60. A minták használata beleillik abba, ahogy én szeretek dolgozni.

B16. Láthatóság (Visibility) A láthatóság annak mértéke, hogy mennyire látható, illetve érzékelhető az innováció az egyén környezetében; látja-e az egyén, hogy mások használják az innovációt. Ha a potenciális adoptáló láthatja, megfigyelheti az innováció használatát azoknál, akik az innovációt már adoptálták, akkor ő is könnyebben fogja adoptálni azt. A láthatóság társakon, szomszédokon keresztül valósul meg, akik valamilyen módon információt adnak az innovációról [MooreGC, 59

Angster Erzsébet: Doktori (PHD) értekezés, 2006 1991]. A DOI elmélet a láthatóságot és az eredmény felmutathatóságát együtt megfigyelhetőség (observability) néven szerepelteti [Rogers, 1995]. Manns kimutatta, hogy a láthatóság pozitív hatással van a minta használatára. Azt azonban nem vizsgálta, hogy a mintahasználat mennyire látható a szoftverfejlesztői szakmában. A kérdőív összeállításánál figyelembe vettem Manns [2002] két kérdését, de én csak egyet fogalmaztam meg: 61. Cégemnél (iskolámban) sokan használnak szoftvermintákat, és ez egyértelműen látható.

B17. Eredmény felmutathatósága (Result demonstrability) Az eredmény felmutathatósága annak mértéke, mennyire világosak az innováció használatának eredményei, mennyire könnyű az eredmény tulajdonságait megfogalmazni, és milyen nehéz ezekről a tulajdonságokról kommunikálni. Ha a potenciális adoptáló láthatja, megfigyelheti az innováció használatának eredményeit azoknál, akik az innovációt már adoptálták, akkor ő is könnyebben fogja adoptálni azt. A eredmény felmutathatósága társakon, szomszédokon keresztül valósul meg, akik valamilyen módon információt adnak az innovációról [MooreGC, 1991]. A DOI elmélet a láthatóságot és az eredmény felmutathatóságát együtt megfigyelhetőség (observability) néven szerepelteti [Rogers, 1995]. Manns kimutatta, hogy az eredmény felmutathatósága pozitív hatással van a minta használatára. Azt azonban nem vizsgálta, hogy mennyire érzékelik eredményesnek a mintahasználatot a szoftverfejlesztői szakmában. A kérdőív összeállításánál figyelembe vettem Manns [2002] kérdéseit: 62. A mintahasználat eredményei nyilvánvalóak számomra. 63. Úgy gondolom, eredményesen tudnék másokkal kommunikálni a minta használatának tanulságairól.

B18. Kipróbálhatóság (Trialability) A kipróbálhatóság annak mértéke, hogy megvan-e a lehetőség arra, hogy az adoptáló (legalább korlátozott mértékben) kipróbálhassa az innovációt, valamint kísérletezzen vele. Nem jár rizikóval vagy túl nagy erőfeszítéssel? Ha az innováció kipróbálható, akkor az kevesebb bizonytalanságot takar. Az egyén sokkal előbb fogadja el az innovációt, ha azt valódi gyakorlattal ismerheti meg, mint más módokon [Rogers, 1995; MooreGC, 1991].

60

5. A mintahasználatot befolyásoló tényezők A minták esetében a kipróbálhatóság valószínűleg összefügg a mintatárház jelenlétével, hiszen ha nincs minta, nincs mit kipróbálni. Egyrészt a minták túl bonyolultak ahhoz, hogy egy egyén próbaképpen mintákat készítsen, majd használja is; másrészt definíció szerint nem minta az, amit nem használtak már többször és többen [The Software Patterns Criteria, 1998]. A kipróbálhatósághoz fontos még a minták kereshetősége is. Hiába van tárház, ha az rosszul szervezett vagy hiányos, vagy egyszerűen nem érhető el. Manns kimutatta, hogy a kipróbálhatóság pozitív hatással van a minta használatára. Azt azonban nem vizsgálta, hogy a mintahasználat kipróbálhatóságát milyen mértékben érzékelik a szoftverfejlesztői szakmában. A kérdőív összeállításánál figyelembe vettem Manns [2002] kérdéseit: 64. Rendelkezésemre áll minden szükséges módszer, technika és eszköz, hogy szakszerűen kipróbálhassam a minták használatát. 65. Úgy gondolom, hogy a minta használatának kipróbálása számomra nagy erőfeszítéssel járna.

A 65. állítás negatív, így a tényező értékének számításánál e válaszérték inverzét kell venni.

5.6.

A mintahasználat érzékelt hatásai

Green et al. [1999] azt állítja, hogy „szignifikáns, pozitív összefüggés van az IT terjedési környezete és a szoftverfejlesztő által érzékelt, IT-re gyakorolt minőségi és produktivitási hatások között”; valamint „szignifikáns, pozitív összefüggés van a szoftverfejlesztő által érzékelt, IT-re gyakorolt minőségi és produktivitási hatások és az innováció terjedési sikere között”. Jelen kutatás vizsgálja, hogy a mintát használók milyen mértékben érzékelik a minőségi és produktivitási változásokat. De fontos megjegyezni: − Green kutatási modelljében jelen van e két tényező, és az adatokat össze is gyűjti a PSP terjedésének vizsgálatára vonatkozóan. Azonban az adatokat nem elemzi – mint mondja, az bonyolultságánál fogva túlmutatna a kutatás keretein; − Manns dolgozatában –, amely a mintahasználatot befolyásoló tényezőket vizsgálja – ezek a tényezők nincsenek jelen; − Mivel a mintahasználat az előzetes felmérések szerint hazánkban még nem terjedt el, valószínűsíthető, hogy a fejlesztők általában nem tudják még érzékelni a terjedési környezet tényezőinek hatását a minőségre, illetve a produktivitásra. A kérdőívben szerepel egy-egy kérdés az érzékelt minőségre és produktivitásra vonatkozóan.

61

Angster Erzsébet: Doktori (PHD) értekezés, 2006 B19. Érzékelt minőség (Percieved Quality) Az érzékelt minőség annak a mértéke, hogy a fejlesztő milyen minőségűnek érzékeli az előállított terméket (szoftvert), ha az innovációt (a mintákat) használja. A kérdőív összeállításánál figyelembe vettem Green et al. [1999] kérdéseit: 66. A minták használatával javul a fejlesztett szoftverek minősége. 67. A minták használatával készített szoftvereket könnyebb karbantartani.

B20. Érzékelt produktivitás (Percieved Productivity) Az érzékelt produktivitás annak a mértéke, hogy a fejlesztő milyen produktívnak érzékeli a munkáját (milyen gyorsan állítja elő a szoftvert), ha az innovációt (a mintákat) használja. A kérdőív összeállításánál figyelembe vettem Green et al. [1999] kérdését: 68. A minták használata nagyban lecsökkenti a szoftverek fejlesztési idejét.

62

6. A felmérés

6.

A felmérés A felmérés elsődleges célja annak vizsgálata, hogy Magyarországon milyen mértékben

használnak mintákat, és hogy a mintahasználatot befolyásoló tényezők milyen értékekkel vannak jelen. Másodlagos cél annak megállapítása, hogy van-e igény az SDP-city weblapra. A szoftverfejlesztési szokásokkal kapcsolatos kérdések értékelését nem tartalmazza ez a dolgozat. A felmérés egy Internetes kérdőív segítségével történt 2004. áprilisában. Ebben a pontban bemutatom a kérdőívet és az adatgyűjtés módját.

6.1.

A kérdőív

A kérdőív az Interneten megtalálható a mellékletben, valamint a következő címen: http://sdp-city.hu/felmeres. A kérdőív elején szerepel a felmérés célja, definíciók (szoftverminta, SDP stb.) és a kitöltési útmutató. Ezt követi a 93 kérdés20 a következő csoportosításban (a Hi és Bi tényezőket az 5.1. ábra foglalja össze): A (1-11): A kitöltő személyes adatai. Itt olyan adatok szerepelnek, amelyek a statisztikai kimutatások szempontjából érdekesek lehetnek. B (12-18): Mintahasználat. H1-H4 tényezőkre vonatkozó kérdések (lásd még: 5.3. pont). C (19-68): A mintahasználatot befolyásoló tényezők. A modellen (5.1. ábra) ezek a B1-B20 tényezők, három csoportban: A mintahasználat terjedési környezete (lásd még 5.4. pont), A mintahasználat érzékelt tulajdonságai (lásd még 5.5. pont) és A mintahasználat érzékelt hatásai (lásd még 5.6. pont). A kérdőíven

20

A kérdőív kérdéseket és állításokat vegyesen tartalmaz. Sok esetben ezeket egyszerűen kérdéseknek fogom nevezni.

63

Angster Erzsébet: Doktori (PHD) értekezés, 2006 ezeket a csoportokat nem tüntetem fel, mert ez a csoportosítás nem tartozik az kitöltőre, és feltehetőleg csak zavarná őt. D (69-76): SDP-city iránti igény: Csak közvetve tartozik a jelen kutatáshoz. Arra voltam kíváncsi, fogják-e használni az SDP keretrendszer konkrét megvalósítását, és hogy melyek azok a tulajdonságok, amelyeken ajánlatos módosítani a használat érdekében. E (77-91): Szoftverfejlesztési szokások: Nem tartozik a jelen kutatáshoz. Arra voltam kíváncsi, melyek az elterjedt szoftverfejlesztési eszközök, eljárások és szokások a különböző célcsoportokban. F (92-93): Összefoglaló vélemény: Itt elmondhatja a kitöltő a kérdőívvel kapcsolatos véleményét. A személyes adatokból a név, e-mail és szervezet adatokat kizárólag az anyag beérkezésének azonosítására használtam. Az azonosításra azért volt szükség, mert statisztikusok szerint (KSH állásfoglalás) Internetes kérdőív kitöltésekor várhatóan sok a kattintgatás. A személyes adatok kitöltését ezért eleinte kötelezővé tettem, 85 kitöltés után azonban ezen adatok megadása már nem volt kötelező, mivel (1) a kitöltők száma nagyon alacsony volt; és (2) személyes beszélgetésekből az derült ki, hogy különböző okok miatt (például üzleti titok) az emberek nem szívesen adják nevüket a kérdőívhez. A válaszok megadásához egy 7 fokozatú Likert skálát választottam, mert ilyen jellegű feladatokra ez egy széleskörűen elfogadott mérési módszer. Green et al. [1999] és Manns [2002] felmérései is ezt a skálát használják. A Likert skála egy 1 és 5 vagy 1 és 7 közötti értékeket ábrázoló egydimenziós mérési skála, mely azt vizsgálja, hogy a kitöltő mennyire ért vagy nem ért egyet egy állítással. Bal oldalon szerepel a „nagyon nem értek egyet”, középen a „semleges”, jobb oldalon pedig a „nagyon egyetértek”. Jelen kérdőív az egyes állításokhoz értelemszerűen igazított válaszokat ad meg a skálán, például: „nagyon nem igaz”, „semleges”, „nagyon igaz”. Minden esetben − bal oldalon szerepelnek a kisebb, illetve negatívabb vélemények; − középen a közepes, átlagos, illetve semleges vélemények; − jobb oldalon pedig a nagyobb, illetve pozitívabb vélemények.

64

6. A felmérés A Likert skála feltételezi, hogy a válaszoló érti magát az állítást. Jelen kérdőív a legtöbb állítás esetén megadja a lehetőséget a „nem tudom” válaszadásra is (csak a biztosan megválaszolható kérdések esetén nem adja meg ezt a lehetőséget). Például: Könnyen szereztem gyakorlatot a mintahasználatban.

nagyon nem igaz

semleges

nagyon igaz

nem tudom

A kérdőívben a lehetséges válaszérték egy 1 és 7 közötti érték; „nem tudom” esetén, illetve ha nem jelöltek be semmit, akkor az érték 0. A 4-es érték jelenti az átlagos, semleges választ. A nulla értékek csak darabszámukkal vesznek részt az értékelésben; az átlag, szórás stb. meghatározásában tehát nem vesznek részt. A kérdőív 93 számozott kérdésből áll, kitöltése előzetes felmérések szerint kb. 30-40 percet vesz igénybe.

6.2.

Az adatgyűjtés módja

A felmérés célcsoportja a Magyarországon élő összes, szoftverfejlesztésben érdekelt egyén. Ezen belül a felmérés négy alcsoportot különböztet meg: fejlesztők, oktatók, tanulók és menedzserek. Az alcsoportokat diszjunktaknak veszem – a kérdőíven a kitöltőnek be kell jelölnie azt az alcsoportot, amelyhez leginkább tartozónak érzi magát. E kutatás keretei nem teszik lehetővé, hogy a teljes célcsoportot maradéktalanul megszólítsam. Nincsen továbbá olyan részcsoport sem, amely jól reprezentálná a teljes célcsoportot és annak négy alcsoportját; ebben a KSH szakembertei is megerősítettek. Adatgyűjtésre ezért a hólabda módszert választottam: egy széles réteg e-mailben történő megszólítása után a kitöltők egymásnak adják át a kérést. A kérdőív elején ez áll: „Kérem, hogy ezt a kérdőívet adja tovább minden, a szoftverfejlesztésben érdekelt fejlesztőnek, oktatónak, tanulónak és menedzsernek!”. Indulásként a következő csoportokat céloztam meg: − IVSZ (Informatikai Vállalkozók Szövetsége); − VISZ (Vezető Informatikusok Szövetsége); − Kb. 10 nagyobb szoftvergyártó cég magyarországi képviselője;

65

Angster Erzsébet: Doktori (PHD) értekezés, 2006 − Kb. 50 egyetemi, főiskolai és középiskolai tanár; − Főiskolai, egyetemi levelezőlisták; − Abakusz szoftverfejlesztői verseny résztvevői 2002-től, kb. 150 tanuló; − Különböző Internetes számítástechnikai újságok levelezőlistája és hirdetőlapja; − Szoftverfejlesztés témájú levelezőlisták. Az egyes cégek vezetői a felhívást továbbadták a munkatársaknak és/vagy a partnereknek. Volt olyan cég, amely ígérete szerint több ezer partnernek küldte ki a kérdőív kitöltését kérő levelet. A „hólabdákat” nem tudtam követni, mert a legtöbb esetben nem kaptam másolatot a szétküldött levélről. Több személytől kaptam visszajelzést, miszerint megkapta a felhívást.

66

7. A kérdőívek részletes elemzése és értékelése

7.

A kérdőívek részletes elemzése és értékelése Többállításos tényezők esetén a válaszértékeket átlagoltam. A negatív módon megfogalma-

zott állítások esetén a válaszértéket a semleges 4-es értékre tükröztem, azaz 7-ből kivontam. Ha a kitöltő az egyes tényezőkhöz tartozó állítások közül legalább egyre válaszolt, akkor a tényező értéke a megválaszolt állítások válaszértékeinek átlaga. Ha egyikre sem válaszolt, akkor a tényező értéke 0, azaz „Nem tudom”.

7.1.

A kitöltő személyes adatai

A kitöltő személyes adatai a 4-11. kérdések. Kitöltők száma: 109 A 113 válaszból 4-et kellett eltávolítani nyilvánvaló kattintgatás miatt (ezekben a kitöltött értékek mind egyenlők: csupa 1-es vagy csupa 7-es). 4. Országok szerinti megoszlás: Magyarország: 103; Románia: 3; Szlovákia: 2; Szlovénia: 1. 5. Nem: Férfi: 93; Nő: 16. 6. Életkor: 0-17 éves 18-24 éves 25-39 éves 40-54 éves 55- éves

4 22 58 22 3

7. Szerepkör: Fejlesztő Oktató Tanuló Menedzser

45 26 29 9

Figyelemre méltó, hogy a menedzser kitöltők száma a többiekhez képest kevés volt (9). 67

Angster Erzsébet: Doktori (PHD) értekezés, 2006 8. Fő tevékenységi körök: Nagyon vegyes 9. Hol tanulta (tanulja) a szoftverfejlesztést? Nagyon vegyes. Szinte mindenki beírta az önképzést is. 10. Szüksége van Önnek arra a tudásra, mellyel egy SDP-t el lehet készíteni? Likert skála értékei: 0: egyáltalán nem, 4: közepesen, 7: nagyon Nem tudom 11/109

Átlag 5.43

Szórás 1.55

Fejlesztők 5.43

Oktatók 5.64

Tanulók 5.27

Menedzserek 5.50

Az SDP fejlesztéséhez szükséges tudásra tehát szükség van (11-en nem tudják). Az egyes szerepkörök között nincs lényeges eltérés. 11. Milyen bonyolultságú szoftvert fejlesztett már? Likert skála értékei: 0: nem fejlesztettem (legfeljebb kisebb programokat írtam), 4: közepeset (kb. az Ingatlanközvetítõhöz hasonló bonyolultságút), 7: lényegesen bonyolultabbat Nem tudom 1/109

Átlag 4.80

Szórás 1.85

Fejlesztők 5.57

Oktatók 4.88

Tanulók 3.11

Menedzserek 5.78

Egy kivétellel mindenki el tudta dönteni, milyen bonyolultságú szoftvert fejlesztett eddig. Részletesebben: − 6-an írták be a legalacsonyabb értéket (nem fejlesztettem, legfeljebb kisebb programokat írtam) – 5 tanuló, egy menedzser; − 25 kitöltő jelölte be a közepeset (kb. az Ingatlanközvetítőhöz hasonló bonyolultságút); − 30 kitöltő írta, hogy lényegesen bonyolultabbat fejlesztett – 16 fejlesztő, 6 oktató, 2 tanuló és 6 menedzser. A többi érték lényegében egyenletesen oszlik el. Ahogy az várható volt, a tanulók fejlesztették eddig a legegyszerűbb szoftvereket. Az oktatók és tanulók esetében az átlag magas értéke elgondolkodtató: ha az oktatók tényleg fejlesztenek ilyen bonyolultságú szoftvereket, akkor miért nem publikálják azokat/miért nem tudnak róla a hallgatók? Az SDP tárház tényező egyik állítása a következő (31. kérdés): „Cégemnél (iskolámnál) vannak korrekt módon elkészített és dokumentált minta-SDP-k, melyek jelentős segítséget adnak az újoncoknak az SDP készítésében.”. A 6 oktatóból, akik nagy bonyolultságú szoftvert fejlesztettek már, 5 oktató erre a kérdésre 1-es értékkel válaszolt. Vagyis az általuk fejlesztett szoftvereket valamilyen ok folytán nem adják oda a tanulóknak.

68

7. A kérdőívek részletes elemzése és értékelése Jellemző megjegyzések: A legtöbb megjegyzés a 11. kérdésre – a fejlesztés módjára és a fejlesztett szoftver bonyolultságára – vonatkozott. Volt aki megjegyezte, hogy egyedül nem szokás ekkora programot fejleszteni: „Szerintem bonyultabb, nagyobb szoftvert inkább csapatban szoktak fejleszteni, a csapaton belül jellemzően ki szoktak alakulni szerepek: van, aki végigviszi az elemzést, míg más inkább tervez, kódol, vagy tesztel.” 7.2.

Vélemények a kérdőívről (92–93. kérdés)

Az utolsó két kérdés (92. és 93. kérdések) a kérdőívvel kapcsolatos véleményeket vizsgálta. Ezeket előre veszem, mert a 93. kérdésre adott vélemények részben megmagyarázzák a bizonytalan és nagy szórású válaszokat. Mivel majdnem minden megjegyzést fontosnak tartok, sokat megadok itt az értékelésben. Az egyszerű dícséreteket elhagytam. A megjegyzések magukért beszélnek: Kérem írja le, amit fontosnak tart, de a kérdőívben nem volt lehetősége kifejteni! 92. kérdés Jellemző megjegyzések: „Egyes problémák megoldási mintái nagyon értékesek lehetnek, de nem tudom, hogy létezik-e ennek a piaca ilyen formában.” „A minták használatának elsajátítása egy lassú folyamat. Ehhez szükség lenne jó könyvekre.” „Kellene tanfolyam komolyabb fejlesztésekhez, hogyan kell csoportban dolgozni...” „Az oktatásban nagyobb hangsúlyt kellene fektetni a minták használatára és készítésére, hiszen véleményem szerint jelentősen meg tudják könnyíteni a munkát, és lerövidíthetik a munkával eltöltött időt is.” „A programozásban azt látom, nagyon fontos, hogy az ember ne maradjon egyedül, tudjon valakikkel beszélni az éppen aktuális feladatról.” „Drágának tartom a gyakorlati ismereteket nyújtó fejlesztői tanfolyamokat.” „Fontos kihangsúlyozni nem csak a design patterneket, hanem az anti-patterneket is...” „Mikor indul az oldal?” „Szinte egyáltalán nincs a szoftverminták használatának magyar nyelvű szakirodalma.”

69

Angster Erzsébet: Doktori (PHD) értekezés, 2006 „Igen sok ilyen tárház van már, ingyenesek, nagyok, valószínű, hogy az Önöké nehezen venné fel ezekkel a versenyt. Mégis látok rá esélyt. A jó kereshetőség, és az alaposan ellenőrzött minőség még a nagy tárházakban sincs meg (lásd Sourceforge). Van egy ötletem, mellyel az sdp-city kitűnhetne a többi közül. Sehol a neten nincs olyan tárház, melyet a fejlesztők munkahelyükön tudnának használni. Szinte minden open-source használhatóságát korlátozza valamilyen jogi kitétel a licenszben. Ha nem a díjfizetési kötelezettség, akkor a szerző feltüntetésének a kötelezettsége akadályozza meg az iparban dolgozó programozót abban, hogy a mások által már többszáz példányban elkészített (és tesztelt) minták, program-könyvtárak valamelyikét felhasználhassa a munkájában. Csak Magyarországon is valószínűleg többen fejlesztik egyszerre ugyanolyan célú mintákat, könyvtárakat. Ha az SDP-cityn meg lehetne találni az ilyen általános célú könyvtárakat, az nagyban növelhetné az ország (vagy az emberiség) szoftverfejlesztési hatékonyságát. Ezzel az érvvel talán állami támogatás is megpályázható lenne (ha az SDP-city csak a magyar nyelvet használná). Sok fejlesztő azonban nem szereti az általa ingyen készített alkotását profitorientált cégek számára is ingyen hozzáférhetővé tenni. Ennek ellenére mégis lehetne találni az SDP-city számára forrásokat. Az egyetemi hallgatók diplomamunkájukként készíthetnének ilyen könyvtárakat. Ez természetesen jó lenne az SDP-city számára, és jó lenne a diákok számára, hiszen diplomamunka-témát, program-könytár fejlesztői tapasztalatot, és publikus referenciát kapnának általa. Az SDPcity esetleg egy szakdolgozat-táma adatbázist is létrehozhatna, melyből a diákok válogathatnának.” Kérem írja le a kérdőívvel kapcsolatos véleményét! 93. kérdés Jellemző megjegyzések: „A kérdőív egészen jó, remélem tudtam segíteni a munkájukat. Sok sikert a továbbiakban.” „Lényegre törő... Könnyen áttekinthető...” „A kérdőív elején van néhány kérdés, amiből egyértelműen kiderül, hogy a kitöltő tudja-e egyáltalán, hogy mi az a szoftverminta. Én nem tudtam ... Számos helyen igazán frusztráló volt, hogy nyilatkoznom kell valamiről, amiről csak sejtem, hogy micsoda...” „Kellene egy nagy [NEM ISMEREM] gomb...” „Én csak olyan mintákat használok, és csak olyannal találkoztam, amiket a tanáraim készítettek, és azt mellékelik mindig valamely programozási feladathoz. Ebből következik, hogy amikor a mintákat értékeltem, csak ezekről tudtam véleményt mondani.” „A kérdőív java része egy olyan fogalomkörre épít, amely a gyakorlatban (számomra és a kollégáim számára) szinte teljesen ismeretlen. Nagyon kockázatosnak tartom, hogy valaki ezekből a válaszokból vonjon le következtetést...” „Úgy gondolom, hogy a dolog lényegét tekintve eléggé átgondolt és kidolgozott.” „Szerintem felesleges kitöltetni valakivel a kérdőívet, ha egyáltalán nem hallott mintákról.” 70

7. A kérdőívek részletes elemzése és értékelése „Igazából nehéz úgy válaszolni a kérdésekre, hogy a minta fogalma nem teljesen világos. Például minta-e egy működő szoftver forráskódja, amelyből lehet ötletet meríteni, de semmi dokumentáció nincs hozzá? Mert ha igen, akkor másképp tölteném ki. Minták helyett forráskódot szoktam olvasgatni, a forrás a legtöbb esteben: http://sourceforge.net/” „Érdekes volt kitölteni, köszönöm a megkeresést! Kíváncsi leszek a végeredményre és annak elemzett értékelésére.” „Összefogott, átgondolt és korrekt.” „Elég részletes az űrlap. Kíváncsi vagyok a végeredményre, és kiváncsi leszek a sitera is, ha elkészül. De legkíváncsibb arra, hogy tud-e működni egy ilyen oldal.” „Szép, jó dolgokat sugall, de az életben minden más. Legalábbis én nem ezzel találkoztam az elmúl tizen-valahány évben.” „Túl sok a kérdés, ez arra ösztönzi az embert, hogy meggondolatlanul válaszoljon...” „Egy tanulónak nem nagyon lehet véleménye e kérdések körében, tapasztalata híján.” „Nagyon szeretném, ha ez a kezdeményezés megvalósulna, sokat segítene munkánkban, s hiszem, hogy mások is szívesen dolgoznának ezért.” „Jól átfogja a témát, strukturált!” „Szerintem elég bonyolult, főleg egy 17 éves diák számára...” „A 18. pontnál meguntam a kitöltést...” „Nagyon hosszú... :)” „A mintahasználatot, az SDP-t és a fejlesztési szokásokat talán külön kérdőíven kellene kérdezni.” „...Köszönöm, hogy segíthettem!” „Érdekes téma. Kíváncsi lennék majd az eredményekre országos szinten.” „Tetszik az SDP-city kezdeményezés, engem mindenképpen érdekelne egy ilyen weboldal.” „Nyilvánvaló a cél, helyes amire törekednek. Remélem sikerrel járnak.” „Amint már valamelyik kérdésnél leírtam, nem tudtam korrekten válaszolni egyes kérdésekre. Mintákat nem használtam eddig, de örömmel vettem e felmérést. A mintákat ha elérhetők számomra, nagyon szivesen fogom alkalmazni.” „Minősége tetszett! Hiányoltam azt a lehetőséget, hogy ha egyszer választottam, utána visszavonhassam a választásomat anélkül, hogy egy másik opciót kellene választanom.” 7.3.

Szoftverminta használat (12–18. kérdés)

A szoftverminta használatot a 12.-18. kérdések mérik fel.

71

Angster Erzsébet: Doktori (PHD) értekezés, 2006 H1. Mintahasználat. 12. kérdés Nem tudom 2/109

Átlag 3.75

Szórás 2.13

Fejlesztők 3.88

Oktatók 4.04

Tanulók 2.72

Menedzserek 5.56

Oktatók 4.38

Tanulók 3.14

Menedzserek 5.89

Oktatók 2.88

Tanulók 2.52

Menedzserek 5.22

Oktatók 1.77

Tanulók 1.83

Menedzserek 2.78

H2. Mintahasználat saját munkában. 13. kérdés Nem tudom 2/109

Átlag 4.11

Szórás 2.19

Fejlesztők 4.23

H3. Mintahasználat csoportosan. 14. kérdés Nem tudom 3/109

Átlag 3.25

Szórás 2.20

Fejlesztők 3.56

H4. Mintahasználat mintaírással. 15. kérdés Nem tudom 4/109

Átlag 2.20

Szórás 1.91

Fejlesztők 2.60

A szoftverfejlesztési körökben leginkább saját munkában használnak mintát (4.11), aztán csoportosan (3.25), mintaírással pedig kevesen foglalkoznak (2.20). A menedzserek a használat minden módjában elöl járnak. Meglepő, hogy az oktatók egyénileg és átlagban jobban használnak mintákat, mint a fejlesztők. E tényezőknél a szórás különösen nagy. Nagyon nagy jelentőségűek a mintahasználathoz csatolt „ellenőrző” kérdésekre adott válaszok. A válaszokból kiderül, hogy a válaszolók általában nincsenek tisztában a minta fogalmával: A 16-18. kérdések ellenőrzést szolgálnak: Hány mintatárházat használ? 16. kérdés Likert skála értékei: 0: nullát, 4: hármat, 7: sokat Nem tudom 3/109

Átlag 2.12

Szórás 1.72

Fejlesztők 1.91

Oktatók 1.62

Tanulók 2.21

Menedzserek 2.56

A szoftverfejlesztői körökben kevesen használnak mintatárházat. Átlagban ugyan kb. egy darabot jelöltek be, de a kitöltők több mint a fele (65-en) azt válaszolta, hogy egyáltalán nem használ mintatárházat. Figyelemre méltó a tanulók magas átlaga az oktatókhoz képest; azonban ezt az átlagot csupán néhány „buzgó” tanuló magasította meg: ők a 17. kérdésre adott válaszukban főként programnyelvi tankönyveket és forráskódokat tartalmazó weblapokat adtak meg.

72

7. A kérdőívek részletes elemzése és értékelése Adja meg az Ön által használt fontosabb mintatárházakat (név, lelőhely, publikus-e)! 17. kérdés A kitöltők a mintákat nem adták meg pontosan: főleg weblapokat és cégneveket neveztek meg (volt például, aki egyszerűen beírta a Sun nevét, de a Sun weblapján található J2EE mintákat konkrétan senki nem említette). Legtöbben (négyen) a GOF könyvet [Gamma et al., 1995] adták meg mint konkrét, publikus tárházat. Pedig a GOF könyv egy szoftver fejlesztéséhez kevés, és túlságosan implementációközeli. Architekturális, webes, vagy GUI mintákat szinte senki nem jelölt meg (két kitöltő megadta Fowler architekturális mintáit). A kitöltők ezekhez hasonló „mintatárházakat” adtak meg például: Tankönyv, help; GOF könyv; Szubrutinok, osztályok; Delphi 5 mesteri szinten; Saját, webes; java.sun.com; A munkahelyen létrehozott szoftverminták (nem publikus); Belső használatú keretrendszer; torry.net; google.com. Egy évre vetítve hány munkanapot tölt el mintakereséssel, megértéssel vagy készítéssel? 18/a kérdés Nem tudom 29/109

Átlag 19.70

Szórás 31.12

Fejlesztők 25.27

Oktatók 9.25

Tanulók 19.43

Menedzserek 17.80

Maximális érték: 200 Egy évre vetítve hány munkanapot takarít meg kész minták használatával? 18/b kérdés Nem tudom 33/109

Átlag 37.92

Szórás 71.77

Fejlesztők 56.97

Oktatók 15.50

Tanulók 27.28

Menedzserek 32.00

Maximális érték: 200 A következő táblázat a megtakarítás és eltöltés hányadosát adja meg a különböző szerepkörökre lebontva. Ebből kiderül: a fejlesztők úgy érzik, hogy 2.25-ször több időt takarítanak meg a minták használatával, mint amennyit eltöltenek vele. Látható, hogy leginkább a fejlesztők, legkevésbé pedig a tanulók érzik úgy, hogy sok munkaidőt takarítanak meg a minták használatával: Idő megtakarítás / eltöltés: Fejlesztők 2.25

Oktatók 1.67

Tanulók 1.40

Menedzserek 1.79

73

Angster Erzsébet: Doktori (PHD) értekezés, 2006 Jellemző megjegyzések a mintahasználathoz: „Több éves szoftverfejlesztői munkám során felhalmozott kódmintákat használok, amelyeket alaposan dokumentálok saját részre, majd rendszerint újra és újra felhasználom őket más projektekben.” „Nem "tárházat", hanem tankönyvet, helpet, java levlistát használok, a mintatárházról most hallottam először.” „A mintának lehet egy lazább definíciója, amikor a múltbeli megoldások ismétlésére kerül sor, anélkül, hogy mintának meg tárháznak neveznénk.” „A szoftverminta újdonság számomra, eddig nem használtam, ezért nem minden kérdésre tudok válaszolni.” „Nem egyértelmű számomra a MINTA fogalma.” „A minták használata sokkal megkönnyíti a programozási munkát, hiszen néha a minták alapján derül ki, hogy hogy érdemes és célszerű egy adott feladatot hatékonyan és gyorsan elkészíteni.” „Munkánkban csak 10% a fejlesztés, a többi mind minták használatán alapul. Tehát 180 napi munkát takarítok meg évente. A baj csak az, hogy a mintákat nem dokumentáljuk, nem fordítunk elég időt ezek rendezésére, átadására, így új fejlesztő képzésekor félév, mire elkezd termelni, egy év mire valóban termelékeny lesz, három év alatt éri el a maximumot. Tehát 600 nap kell, hogy minden lényeges mintát magáévá tegyen.” (Az eredeti szövegben a 180 helyett 1800 nap volt, ami nyilvánvaló elírás.) „Kevés a fellelhető, megbízható minta, inkább csak forráskódok találhatók.” „A kódminták nélkül egyáltalán nem tudnék fejleszteni.” „Technológia kutatással foglalkozok, így a mintákat, amiket találok és kitalálok, mások hasznosítják. Ők évente fejenként megtakarítanak 30-40 napot ezáltal.” „Eddig nem használtam mintát, de szívesen használnék. Ennek figyelembevételével kérem értékeljék a következő kérdésekre adott válaszaimat.” A Mintahasználat összefoglaló értékelése: A szoftverfejlesztői közösség átlag alatt használ mintát (3.75). Leginkább a menedzserek vallják azt, hogy használnak mintákat, bár a menedzser kitöltők száma kevés volt (9). Ezután az oktatók következnek (4.04), aztán a fejlesztők (3.88), végül a tanulók (2.72). A mintahasználat főleg egyéni használatban merül ki (az egyéni mintahasználat átlag értéke 4.11), ami azt jelenti, hogy publikus mintákat használnak önálló fejlesztésekben. Csoportosan már kevesebben használnak mintát (átlag értéke 3.25). Mintát nagyon kevesen írnak (2.20). A konkrét mintatárházak megadásából és a megjegyzésekből arra lehet következtetni, hogy a mintát sokan félreértelmezték, és mintának vették többek között az ellenőrizetlen idegen kódrészleteket, komponenseket és saját készítésű szoftverelemeket. A hallgatók többsége minta alatt a

74

7. A kérdőívek részletes elemzése és értékelése saját tanárától kapott feladatok megoldásait érti. A kitöltők egyértelműen úgy gondolják, hogy jelentős munkaidőt takarítanak meg a minták használatával: kb. kétszer annyi időt takarítanak meg, mint amennyit a minták keresésére szánnak (fejlesztők: 2.25, tanulók 1.40).

7.4.

A mintahasználatot befolyásoló tényezők (19–68. kérdés)

A mintahasználatot befolyásoló tényezők három csoportja (a mintahasználat terjedési környezete (B1-B12), a mintahasználat érzékelt tulajdonságai (B13-B18) és a mintahasználat érzékelt hatásai (B19-B20) a kérdőíven nincs szétválasztva. B1. Újdonság foka (Degree of novelty). 19-21. kérdések Nem tudom 4/109

Átlag 4.54

Szórás 1.56

Fejlesztők 4.42

Oktatók 4.79

Tanulók 4.73

Menedzserek 3.85

Jellemző megjegyzések: „Bár biztos vagyok benne, hogy tanáraim ismerik és használják a szoftvermintákat, a programozás kurzuson sajnos nem volt róluk szó.” „A példaprogram ismerős számomra. Egyebet nem ismerek.” „... elég ritkán használunk más mintákat a könyvtári programokon kívül.” „Némi kereséssel elérhetőek a publikus mintatárak, a használatuk már nehézkesebb, de a puszta olvasásuk is nagy segítség.” Értékelés: A mintahasználat általában új az embereknek (4.54). A minta fogalma legkevésbé a menedzsereknek új, a fejlesztőknek, oktatóknak és tanulóknak lényegében egyformán újdonság a mintahasználat. A 109-ből öszesen 4-en nem tudták megmondani, hogy számára új-e ez a fogalom. Ők valószínűleg nincsenek tisztában a minta fogalmával. B2. Innovatív szándék (Innovativeness). 22-23. kérdések Nem tudom 3/109

Átlag 5.34

Szórás 1.23

Fejlesztők 5.48

Oktatók 5.30

Tanulók 4.95

Menedzserek 6.00

Jellemző megjegyzések: „... projekt munkában tudom hatékonyan elképzelni, és a team hozzáállásától is függ. Mindenképpen kezdeményező lennék a bevezetésénél.” „Néha túlságosan is szeretjük az új dolgokat.”

75

Angster Erzsébet: Doktori (PHD) értekezés, 2006 Értékelés: A szoftverfejlesztői közösség innovatív (5.34). Leginkább a menedzserek innovtívak (6.00), legkevésbé a tanulók (4.95). B3. A fejlesztő bevonása (User involvement). 24-26. kérdések Nem tudom 3/109

Átlag 3.26

Szórás 1.83

Fejlesztők 3.56

Oktatók 3.55

Tanulók 2.25

Menedzserek 4.11

Jellemző megjegyzések: „Szeretnék részt venni a mintahasználat koncepcionális kialakításában. Remélem lesz rá mód.” „Sem én sem a kollégáim nem tudjuk elképzelni, hogyan néz ki egy mintatárház, illetve hogyan kellene használni.” „[A mintatárházak] megjelenése csak dedikált rendszerházaknál várható. A ma divatos egyéni fejlesztői rendszerek nem kedveznek az összmunkának.” „A főiskolán a közös vizsgabankokat már a mintahasználat csírájának tartom.” Értékelés: A fejlesztőket nem igazán vonják be mintatárházak kialakításának és működtetésének a munkájába (az átlag 3.26), főleg a tanulókat nem, ott az érték 2.25. B4. Mintatárház (Patterns repository). 27-29. kérdések Nem tudom 3/109

Átlag 3.42

Szórás 1.51

Fejlesztők 3.92

Oktatók 2.69

Tanulók 3.23

Menedzserek 3.52

Jellemző megjegyzések: „Válaszom akkor érvényes, ha a példaprogramokat mintáknak hívjuk.” „Itt is hasznos lett volna a "nem tudom" opció.” „Nem tudok ezek létezéséről.” „Semleges, mert nem használok. Nincs "nem tudom" gomb.” „Még mindig kérdés mi a minta és mi a minta tárház...” Értékelés: A szoftverfejlesztői közösségnek kevés mintatárház áll rendelkezésére (az átlag 3.42). A legtöbb mintatárházat a fejlesztők találják, de még ez sem éri el a közepes, „semleges” szinet (3.92). Leginkább az oktatók érzik úgy, hogy nincs elegendő minta (2.69). A megjegyzésekből kitűnik, hogy a kitöltők nem jól értelmezik a mintát, illetve még nem találkoztak ezzel a

76

7. A kérdőívek részletes elemzése és értékelése fogalommal a szoftverfejlesztésben. Sajnos minta alatt sokan forráskódot vagy programnyelvi könyvet értenek; az érték ennek ellenére átlag alatti. B5. SDP-tárház (SDP repository). 30-33. kérdések Nem tudom 3/109

Átlag 2.79

Szórás 1.25

Fejlesztők 3.04

Oktatók 2.24

Tanulók 2.77

Menedzserek 3.19

Jellemző megjegyzések: „Tájékozatlan vagyok.” „Nem ismerem az SDP-t, tehát nem is tudom mennyire ellátott az internet.” „Egyáltalán nem találkoztam még SDP-vel.” „A semlegesnél pozitívabb választ a GDF SDP-city indítás próbálkozására adtam.” „SPD helyett valamilyen hasonló, előzőleg fejlesztett programot használunk "mintának". De ez általában hiányosan dokumentált, "szájhagyomány" útján ismerhető meg.” „Ha az SDP a szakirodalomban nem szereplő szó, akkor hogy lehetne valakinek SDP tárháza? Vagy lehet, hogy van neki, csak nem tud róla, hogy így hívják?” Értékelés: A szoftverfejlesztői közösségnek nagyon kevés SDP áll rendelkezésére (az átlag 2.79). A legtöbb SDP-t a menedzserek találják, de még ez is alacsony értékű (3.19). Leginkább az oktatók érzik úgy, hogy nincs elegendő SDP (2.24). A megjegyzésekből is kiderül, hogy az SDP-re eddig nem volt megfelelő kifejezés. B6. Élharcos (Champion). 34-35. kérdések Nem tudom 5/109

Átlag 4.05

Szórás 1.91

Fejlesztők 4.02

Oktatók 4.18

Tanulók 3.78

Menedzserek 4.67

Jellemző megjegyzések: „A magam ura vagyok. A legfontosabb, hogy müködjön!” „Mindenki szabadon eldöntheti, hogy használ-e mintát. A belső forráskódból élünk, a reprodukciós hatás alacsony, így még nem központi ügy a minták kezelése.” „A cégemben saját vezetőm vagyok, illetve az iskolában Te (Anster E.) támogatod...” „A főnökömet nem érdekli.”

77

Angster Erzsébet: Doktori (PHD) értekezés, 2006 Értékelés: Az élharcos jelenléte „semleges” (4.05), vagyis a főnökség nem támogatja a mintákat, de nem is akadályozza annak használatát. A legjobban a menedzserek érzékelik a cég támogatását (4.67), legkevésbé a tanulók (3.78). B7. Véleményvezető (Opinion leader). 36-37. kérdések Nem tudom 3/109

Átlag 3.38

Szórás 1.78

Fejlesztők 3.59

Oktatók 3.18

Tanulók 3.11

Menedzserek 3.78

Jellemző megjegyzések: „A java levlistán látom ennek nyomait.” „Munkatársaimtól függetlenül használom a mintákat.” „Korábbi tapasztalataim alapján: közös rutingyüjteményünket is volt aki később sajátjának tekintette és maga fejlesztette tovább, és nem tette közkinccsé a bővítést.” Értékelés: A szoftverfejlesztői közösség tagjai közelében nem jellemző az olyan emberek jelenléte, akik véleményükkel befolyásolnák és előmozdítanák a mintahasználatot (az átlag 3.38). A legjobban a menedzserek érzékelik a véleményvezető jelenlétét, (3.78), legkevésbé a tanulók (3.11). B8. Változási ügynök (Change agent). 38-39. kérdések Nem tudom 3/109

Átlag 2.61

Szórás 1.79

Fejlesztők 2.60

Oktatók 2.42

Tanulók 2.64

Menedzserek 3.06

Jellemző megjegyzések: „Nem hiszem, hogy ezt intézményesíteni kell. Ez hozzátartozik egy fejlesztő alapműveltségéhez.” Értékelés: A szoftverfejlesztői közösség tagjai közelében nagyon kevés olyan ember van, akik lobbiznának a mintahasználat ügyében (az átlag 2.61). Még a legjobban a menedzserek érzékelik a változási ügynök jelenlétét, (3.06), legkevésbé az oktatók (2.42). B9. Oktatás (Training). 40-43. kérdések Nem tudom 3/109

78

Átlag 2.53

Szórás 1.43

Fejlesztők 2.73

Oktatók 2.17

Tanulók 2.46

Menedzserek 2.81

7. A kérdőívek részletes elemzése és értékelése Jellemző megjegyzések: „Ilyen cél-oktatás tudtommal nincs.” „Önképzéssel megy csak ...” „Hol van ilyen oktatás?” „Jelen fejlesztési kihívásunk alapján nem lényegi kérdés a minták használata.” Értékelés: A szoftverfejlesztői közösség tagjainak lényegében nem áll rendelkezésére mintahasználattal kapcsolatos oktatás (az átlag 2.53). Sokak szerint a magyarországi szoftverfejlesztő képzés meglehetősen távol áll a piaci igényektől. A szerepkörök között alig van különbség, de a legrosszabb helyzetben az oktatók vannak (2.17). B10. Tananyag (Teaching material). 44-47. kérdések Nem tudom 3/109

Átlag 3.17

Szórás 1.39

Fejlesztők 3.40

Oktatók 2.96

Tanulók 2.82

Menedzserek 3.69

Jellemző megjegyzések: „Nem ismerek tananyagokat.” „Tananyag?! ... Az egész élet egy nagy tananyag.” Értékelés: A szoftverfejlesztői köröknek kevés tananyag áll rendelkezésre (az átlag 3.17). A tananyaggal leginkább a menedzserek vannak megelégedve, de még az is a „közömbös” alatt van (3.69). A tanulók nagyon elégedetlenek a fellelhető tananyagokkal (2.82). Talán ez is jelzi, hogy több az áttekintő, és kevesebb a gyakorlati jellegű tananyag. B11. Bevezetett eljárás (Installed process). 48-50. kérdések Nem tudom 3/109

Átlag 2.46

Szórás 1.65

Fejlesztők 2.92

Oktatók 1.77

Tanulók 2.17

Menedzserek 3.00

Jellemző megjegyzések: „Nincs kötelező mintahasználat.” „Cégemnél nem használnak mintát.” Értékelés: Az embereknek nem kell megadott szabványok és ejárások szerint használniuk a mintákat (az átlag 2.46). A fejlesztők és menedzserek cégénél jobban vannak bevezetett eljárások (2.92, illetve 3.00) mint az oktatóknál, ahol szinte egyáltalán nincs ilyen (1.77). 79

Angster Erzsébet: Doktori (PHD) értekezés, 2006 B12. Fórum. 51-52. kérdések Nem tudom 3/109

Átlag 2.15

Szórás 1.80

Fejlesztők 2.28

Oktatók 1.66

Tanulók 2.11

Menedzserek 2.94

Jellemző megjegyzések: „Szeretnék például tagja lenni az általad (AE) vezetett csoportnak”. „Tag lennék, ha tudnám hol vannak a fórumok.” Értékelés: A szoftverfejlesztői közösség tagjainak lényegében nincs meg a lehetősége a mintahasználatról történő eszmecserére (az átlag 2.15). A menedzserek helyzete a legjobb (2.94), az oktatóké a legrosszabb (1.66). B13. Hasznavehetőség (Usefulness). 53-55. kérdések Nem tudom 2/109

Átlag 5.57

Szórás 0.90

Fejlesztők 5.69

Oktatók 5.30

Tanulók 5.37

Menedzserek 6.29

Jellemző megjegyzések: „... igaziból alig várom, hogy megszerezzem az első tapasztalatokat, mivel maga az ötlet nagyon szimpatikus.” „... Newton se azzal kezdte, hogy feltalálta a szorzást. Jó példaprogramokból meszszebbre juthat, aki kreatívan használja azokat.” „... nem érdemes újra megírni, ami már megvan.” „Szerintem nem igaz, hogy a minták használatával az emberek elvesztik kreatívitásukat, sőt egy-egy jó minta alapján lehet néha sokkal jobb dolgokat alkotni.” „Véleményem szerint az idővel jobban tud gazdálkodni az ember, és esetleg saját ötletei megvalósítására több idő jut.” „Néha persze lehet túlságosan sok mintát használni, ami rontja a kódot, és lehet rosszul is használni (ezeknek is van irodalma, Antipatterns-nek hívják őket).” Értékelés: A potenciális mintahasználók elég hasznosnak érzik, illetve gondolják a mintahasználatot. Az átlag 5.57, és az érték mindegyik szerepkörben 5.30 feletti. A mintanasználat hasznavehetőségét leginkább a menedzserek érzékelik (értéke 6.29, közelíti a maximumot), aminek az lehet az oka, hogy a szoftverfejlesztés költségei leginkább a menedzsereket értinti. Az aránylag kis szórás arra enged következtetni, hogy a kitöltőknek határozottabb a véleményük a hasznavehetőségről.

80

7. A kérdőívek részletes elemzése és értékelése B14. Könnyű használat (Ease of use). 56-58. kérdések Nem tudom 8/109

Átlag 4.84

Szórás 1.06

Fejlesztők 4.96

Oktatók 4.49

Tanulók 4.71

Menedzserek 5.52

Jellemző megjegyzések: „Bár jobban szeretem magam megoldani a fejlesztési feladatokat, tény, hogy a minták használata megkönnyíti a fejlesztést.” „Csak akkor [könnyű a használata], ha a minta nem "bugos".” Értékelés: Az emberek úgy gondolják, hogy ha használnának mintákat, akkor az nem ütközne különösebb nehézségekbe (az átlag 4.84). Legkönnyebbnek a menedzserek gondolják a mintahasználatot (5.52), a legnehezebbnek az oktatók (4.49), de még ez az érték is átlag feletti. Ennél a tényezőnél magasabb a "nem tudom"-ok száma (8): ha valaki nem használt még mintát, akkor nem tudja, könnyű-e használni. B15. Kompatibilitás (Compatibility). 59-60. kérdések Nem tudom 10/109

Átlag 5.27

Szórás 1.47

Fejlesztők 5.26

Oktatók 5.52

Tanulók 4.84

Menedzserek 5.93

Jellemző megjegyzések: „Komponens, illetve szabvány értelemben adtam meg a választ.” „Amíg a remény él, addig jó :)” Értékelés: Az emberek úgy érzik, hogy a mintahasználat kompatíbilis munkájukkal (az átlag 5.27). A menedzserek érzik így a legjobban (5.93), legkevésbé a tanulók, de még ez is magas érték (4.84). Itt a „nem tudom”-ok száma elég magas (10), vagyis sokan nem tudják, hogy a mintahasználat kompatíbilis-e munkájukkal. B16. Láthatóság (Visibility). 61. kérdés Nem tudom 18/109

Átlag 2.66

Szórás 2.02

Fejlesztők 2.92

Oktatók 2.24

Tanulók 2.39

Menedzserek 3.25

Jellemző megjegyzések: „Elsősorban a gyártási, minőségbiztosítási munkára igaz, de arra nagyon.” „Nem tudom, mert nem nagyon hallottam róla, hogy valaki mintát használna.”

81

Angster Erzsébet: Doktori (PHD) értekezés, 2006 Értékelés: A szoftverfejlesztői közösség nem igazán látja maga körül a mintahasználatot. A szórás feltűnően magas (2.02), vagyis nem az a jellemző, hogy egy ember „kicsit látja”, hanem az, hogy vagy látja, vagy nem látja. Az átlag érték azonban itt is nagyon alacsony (2.66), vagyis az emberek többsége nem látja. Legjobban a menedzserek látják (3.25), legkevésbé az oktatók (2.24), ami igencsak elgondolkodtató, hiszen a tanulók az oktatóktól tanulnak. Ez az ellentmondás természetesen betudható a mintáról alkotott téveszméknek is. A "nem tudom"-ok száma itt kiugró; 18-an nem tudják, hogy látják-e a mintahasználatot; ez csak úgy lehetséges, ha nem tudják, mit kell látni. B17. Eredmény felmutathatósága (Result demonstrability), 62-63. kérdések Nem tudom 3/109

Átlag 4.32

Szórás 1.93

Fejlesztők 4.72

Oktatók 4.34

Tanulók 3.41

Menedzserek 5.11

Jellemző megjegyzések: „Csak az optimizmusom és egyéb téren szerzett tapasztalataim diktálják ezt a [pozitív] választ.” Értékelés: A kitöltők számára a mintahasználat eredményei nem világosak, de az érték az átlagosnál nagyobb (4.32). Sok fejlesztő cég küszködik a mintagyűjtés és betanítás problémájával, még azok is, akik tisztában vannak a várható haszonnal. A menedzserek vannak leginkább tisztában az eredmény felmutathatóságával (5.11), a tanulók pedig a legkevésbé (3.41). B18. Kipróbálhatóság (Trialability). 64-65. kérdések Válaszok száma 5/109

Átlag 3.98

Szórás 1.84

Fejlesztők 4.19

Oktatók 3.60

Tanulók 3.82

Menedzserek 4.50

Jellemző megjegyzések: „Ezt a végfelhasználó ingyen is megteszi.” Értékelés: Az eredmény teljesen átlagos (3.98). A menedzserek úgy érzik, hogy jobban ki tudják próbálni a mintahasználatot (4.50) talán azért, mert nekik nagyobb tapasztalatuk van a fejlesztésben és a modulok/komponensek keresésében. A tanulók tudják legkevésbé kipró-

82

7. A kérdőívek részletes elemzése és értékelése bálni a mintahasználatot (3.60). Egyetlen kitöltő írt megjegyzést, ő láthatóan félreértette a kérdést. B19. Érzékelt minőség (Percieved quality). 66-67. kérdések Nem tudom 3/109

Átlag 4.86

Szórás 2.13

Fejlesztők 4.89

Oktatók 4.72

Tanulók 4.63

Menedzserek 5.83

Jellemző megjegyzések: „Csak akkor javul a minőség, ha a minták korrektek!” „A mintákról olvasottak alapján feltételezem, hogy mindkét megállapítás igaz, de tapasztalat híján nem tudom.” „Csak akkor van gond, ha a minta változik, és a szoftver már nagyon régen nem lett újrafordítva.” „Mivel a minták pl. Javában eléggé újak, ezért sok baj van velük. Sokat kell tesztelni. Elég idegesítő, amikor egy mástól szerzett dolog nem jól működik.” Értékelés: A szoftverfejlesztői közösség úgy érzékeli, hogy a minta haszálatával munkájának a minősége kicsit jobb lesz (4.86, a szórás nagy). Ezt leginkább a menedzserek érzékelik így (5.83). Itt is vannak félreértések: az utolsó megjegyzésben például nem mintáról van szó, hiszen a minta már jól bevált – többen, több alkalommal kipróbálták. B20. Érzékelt produktivitás (Percieved productivity). 68. kérdés Nem tudom 4/109

Átlag 5.31

Szórás 2.04

Fejlesztők 5.41

Oktatók 5.42

Tanulók 4.89

Menedzserek 5.89

Jellemző megjegyzések: „Ha jó az általunk írt interfésze, akkor igen.” „Ez sok mindentől függ!” „Ez csak elképzelés részemről.” „Elsősorban a kockázatot csökkenti, nem az időt.” Értékelés: A kitöltők úgy érzékelik, hogy a mintahasználattal jelentősen megnövekszik a produktivitásuk (5.31, a szórás itt is nagy). Itt is a menedzserek látják leginkább pozitívnak a helyzetet (5.89), a legkevésbé pozitívnak pedig a tanulók (4.89).

83

Angster Erzsébet: Doktori (PHD) értekezés, 2006 7.5.

SDP-city iránti igény (69-76. kérdés)

Ez a kérdéscsoport azt méri fel, hogy a szoftverfejlesztői közösség hogy viszonyul az SDPcity weblaphoz. Megjegyzést itt a teljes kérdéscsoportra lehetett adni. Szívesen használnám az SDP-city weboldalt. 69. kérdés Likert skála értékei: 0: nagyon nem igaz, 4: semleges, 7: nagyon igaz Nem tudom 22/109

Átlag 5.61

Szórás 1.05

Fejlesztők 5.47

Oktatók 5.83

Tanulók 5.33

Menedzserek 6.20

Értékelés: A szoftverfejlesztési körökben szívesen használnák az SDP-city weblapot (átlag=5.61, nem tudja: 22; nem használná: 3; nagyon használná: 34). Szívesen kitennék én is az SDP-cityre saját fejlesztésű mintát vagy SDP-t. 70. kérdés Likert skála értékei: 0: nagyon nem igaz, 4: semleges, 7: nagyon igaz Nem tudom 22/109

Átlag 4.90

Szórás 1.84

Fejlesztők 4.57

Oktatók 5.39

Tanulók 4.87

Menedzserek 5.00

Értékelés: A szoftverfejlesztési körökben módjával tennének ki értéket az SDP-city weblapra (átlag= 4.90, nem tudja: 22; nem tenne ki: 6; nagyon kitenne: 23). Figyelemre méltó, hogy leginkább az oktatók tennének ki értéket a lapra, legkevésbé pedig a fejlesztők. Mennyi pénzt kapjon az alkotó például egy zsűrizett Ingatlanközvetítő SDP-ért? 71. kérdés Likert skála értékei: 0: ne kapjon: Elegendő a szakmai és erkölcsi megbecsülés, 4: 100 eurót 7: >1000 eurót Nem tudom 43/109

Átlag 4.14

Szórás 1.96

Fejlesztők 3.81

Oktatók 4.71

Tanulók 3.90

Menedzserek 5.2

Értékelés: A szoftverfejlesztési körökben úgy gondolják, hogy átlagban kicsit 100 Euró felett adnának az alkotónak egy átlagos nagyságú, zsűrizett SDP-ért. Nagyon sokan azonban nem tudják a választ (43), és a szórás nagy (1.96). A legnagyobb összeget a menedzserek mondták, a legkisebbet a fejlesztők. 84

7. A kérdőívek részletes elemzése és értékelése Mennyi pénzt kapjon a pásztor egy zsűrizett terelgetésért (kb. 30 órai munkáért)? 72. kérdés Likert skála értékei: 0: ne kapjon: Elegendő a szakmai és erkölcsi megbecsülés, 4: 100 eurót 7: >1000 eurót Nem tudom 46/109

Átlag 3.49

Szórás 1.73

Fejlesztők 3.42

Oktatók 3.77

Tanulók 3.38

Menedzserek 3.67

Értékelés: A szoftverfejlesztési körökben úgy gondolják, hogy átlagban 100 Euró alatt adnának a pásztornak egy átlagos nagyságú, zsűrizett SDP pásztorolásáért. Nagyon sokan azonban nem tudják a választ (46), és a szórás nagy (1.76). A legnagyobb összeget az oktatók és a menedzserek mondták Szívesen támogatnám (én vagy a szervezetem) a weboldalt a működés érdekében, évenként kb. ennyi euróval. 73. kérdés Likert skála értékei 1 és 7 között: 0, 1-9, 10-49, 50-199, 200-499, 500-999, 1000+ Nem tudom 58/109

Átlag 1.94

Szórás 1.33

Fejlesztők 2.29

Oktatók 1.80

Tanulók 1.76

Menedzserek 1.00

Értékelés: A szoftverfejlesztési körökben lényegében nem támogatnák az SDP-city-t, bár nagyon sokan nem tudják a választ (58). Legjobban a fejlesztők támogatnák (2.29); a menedzserek egyáltalán nem támogatnák a lapot anyagilag (bár ők csak 9-en vannak). Örülnék, ha a lapon levő minden alkotás nyílt dokumentációjú és forráskódú lenne. 74. kérdés Likert skála értékei: 0: nagyon nem igaz, 4: semleges, 7: nagyon igaz Nem tudom 10/109

Átlag 6.19

Szórás 1.19

Fejlesztők 6.28

Oktatók 6.38

Tanulók 6.04

Menedzserek 5.71

Értékelés: A szoftverfejlesztési körökben sokan szeretnék, hogy az SDP-city minden alkotása nyílt dokumentációjú és forráskódú lenne (atlag: 6.19). Leginkább az oktatók szeretnék így (6.38), legkevésbé a menedzserek (5.71).

85

Angster Erzsébet: Doktori (PHD) értekezés, 2006 Tisztában vagyok a nyílt dokumentáció és forráskód fogalmával (open documentation, open source). 75. kérdés Likert skála értékei: 0: nagyon nem igaz, 4: semleges, 7: nagyon igaz Nem tudom 5/109

Átlag 6.31

Szórás 1.02

Fejlesztők 6.58

Oktatók 6.08

Tanulók 6.18

Menedzserek 6.00

Értékelés: A szoftverfejlesztési körökben nincsenek teljesen tisztában a nyílt dokumentáció és forráskód fogalmával (átlag: 6.31). Leginkább a fejlesztők vannak tisztában a fogalommal (6.58), legkevésbé a menedzserek (6.00). Milyen anyagi, jogi és emberi feltételek mellett lenne életképes egy ilyen weboldal? 76. kérdés Jellemző válaszok: „Ha oktatás során hozzászoknának, akkor a lassú népszerűségszerzés nem reménytelen. Csak a már munkában levők szerintem nem csatlakoznának. Ők már működnek valahogy.” „Nem tudom, de ha én akarnám megcsinálni, biztos keresnék szponzorokat. Az alkotók és a pásztorok lehetőséget kapnának arra, hogy eldöntsék: kérnek pénzt a munkájukért, vagy megteszik lelkesedésből, illetve hogy le szeretnék-e védeni a saját mintájukat és milyen mértékben. Lenne több fajta szerződés és az egyes minták mellett ott lenne a kategória.” „Itthon a többség nem szívesen fizet szellemi termékekért (főleg akkor nem, ha más forrásból ingyen is beszerezheti azt). Szerintem ezért nem sikeresek a fizetős oldalak. Aki elérhetővé teszi szellemi termekeket, ingyen tegye.” „Kell egy főgazdi, akinek szívügye, és vigyáz a minőségre=>szakember. Az elimerés is kell, de nem pénzben, hanem pl. kreditben. Kreditek száma=szakmai elismerés foka... Ez később szakmai referenciaként is szolgálhat álláskeresésnél....” „Kellenek mentorok, szponzorok, elhivatott pásztorok...” „Működési feltételek: 1. A termékeket üzleti célra is fel kellene tudni használni; 2. Nyílt forráskód, módosítási lehetőséggel; 3. Megfelelő minőség.” „Kell sok lelkes ember, és kevés L(GPL).” „Jól képzett és fizetett webmesterek munkája esetén.” „Szerintem nem a forráskódról van szó, hanem módszerekről, technológiákról, dokumentációkról. Ha a forráskód megjelenik valahol, az legyen szabadfelhasználású, de ne legyen GPL. Tehát ne kelljen publikálnom, hogy felhasználtam a mintát.”

86

7. A kérdőívek részletes elemzése és értékelése „Sok társadalmi munkát, lelkes gárdát és elkötelezett gárdát igényel, megtérülés csak hosszú távon várható.” „Elhivatott pásztorokra van szükség és olyan alkotókra, akik igényességre törekszenek saját munkájukat illetően.” „Mozgalmi jelleg, önkéntesség, önkéntes felajánlások, szponzorok szerzése.” „Anyagi elismerés helyett szakértői minősítés, valóban alkalmazható, gyakorlatias témák tárgyalása.” „Ha az egyszerűbb feladatok freeware-ek, a komolyabbak pedig fizetős minták lennének.” „Sok fejlesztőre, pásztorra van szükség, hogy pezsegni tudjon az élet az SDP-cityben. Jogilag minden szellemi terméket védeni kell de az "open"-es licenszek szerintem elegendőek. Anyagilag... ha a közösség életképes, egymást úgy is megfelelően honorálják.” „Szerintem erre jó példa a PostgreSQL (postgresql.org) oldal, ahol egy elég kiterjedt hasonló tevékenység folyik fórumokkal, példákkal, opensource és dokumentációk. Fontosnak tartanám, hogy ne csak a magyar fejlesztők használhassák az oldalt, mert a Mo.-on szerintem nincs hozzá elég potenciál.” „Kell szponzor, s elhivatott pásztorok...” „Szerintem semmilyen. Előbb utóbb warez oldalon találkoznánk vele ha fizetős lenne, ha meg nem, akkor miből a fejlesztő-pásztor fizetése?” „Dedikált belépés, és dedikált felhasználás a minta alkotójának kemény munkája miatt.” „Személyes tapasztalatom szerint aki ilyen weboldal használatából már profitált, szívesen együttműködik és használja továbbra is a szolgáltatásokat.” „... egyszerű rutinok ingyen, összetett megoldások felhasználásonkénti fizetéssel.” „Kellene pár cég és alapítvány (mint az Jakarta...)” „Az alkotók nevének, elérhetőségének megadása az SDP-kben. Megfelelő szakmai háttérrel rendelkező fejlesztőkre és pásztorokra lenne szükség. Folyamatosan frissüljön, jól átlátható legyen a site szerkezete, könnyen lehessen keresni (!!!!), ami azt jelenti, hogy fejlett, jól használható részletes keresővel is el kell látni.” „Szerintem előfeltétel, hogy olyan problémákkal is foglalkozzon, amit a gyakorlatban is fel lehet használni. A probléma ott van, hogy általában az ilyen megoldásokat nem szokás nyilvánosságra hozni.” „Maga az Open Source kezdeményezés már bevált, gondolom működőképes lenne SDP-knél is, mindenesetre az említett pásztorlásért és az SDP-ért járó jogdíjak jelentős anyagi erőforrásokat igényelnek. Más Open Source kezdeményezés hátterét nem ismerem (pl. miből tartják fenn az Apache Jakartát, ahol nagyon színvonalas eszközöket találhat a fejlesztő)...” „Emberi: szakmailag képzett pásztorok. Jogi: nyílt forráskód... Anyagi: állami-céges támogatás vagy minták utáni egyszeri "jogdíj" az alkotónak és a honlapnak.” „Szerintem a postgresql fejlesztési módszere nagyon jól működik és követendő példa lehet minden ilyen szervezet számára.” 87

Angster Erzsébet: Doktori (PHD) értekezés, 2006 „Ha anyagi, jogi és emberi feltételek nem játszanának szerepet.” Jellemző megjegyzések a teljes kérdéscsoporthoz: „... munkával hozzájárulnék [a cityhez], pénzzel sajnos nem.” „A pénzre vonatkozó kérdések értelmetlenek a feladat nagysága (vagyis a ráfordított erőforrások) ismerete nélkül. A piaci viszonyok is nagyban befolyásolják...” „...a cégem, illetve saját erőforrásaim megfelelőek számomra.” „A pénzzel kapcsolatos megoldások nekem inkább egy shareware jellegű forgalmazást tennének inokolttá. Viszont minden esetben a feladat bonyolultsága is kell, hogy befolyásolja az árat. A nyílt dokumentáció nyilvánvalóan ellentmond a fenntarthatóságnak.” „Meglehetősen elkötelezett híve vagyok az SDP-citynek, így a véleményem biztosan SDP-párti :-)” „Nem adnám közre azt az SDP-t (munkaezközt), amit én azért írtam, hogy később a segítségével kevesebbet kelljen dolgoznom. Viszont az olyan dolgokat, amiből "nem lehet megelni" hanem csak szórakoztató jellegűek - szívesen közreadnám (3d grafika/hang). 71: megrendelőtől függően havi netto 30-50ezer Ft-t. (es ebben benne van a support is...). „Egy cégnél az SDP-k piacképes használata új szabályozásokat vetne föl véleményem szerint. Garancia vállalás az új termék használatához.” „Én azt nem értem már sok éve, hogy miért nem szabad a pénzért fejlesztett szoftver; mert lehetne az, megfelelő érdekeltséget teremtő szabályokkal. Ezért nem tudom, hogy az ingyenesség felé menő dolgok mennyire életképesek. Pl. a Linuxban mindenre van sok ezer ócska program, de a színvonal csúcsán lévő alig.” „A szakmai megbecsülés mellett fontos, hogy anyagilag is támogatást kapjon egy fejlesztő, akármilyen minősítésben is vállal szerepet. A Pásztor és a terelgetett egyén együttes díjazását preferálom, hiszen együttes munka eredménye lett az elkészült minta vagy SDP.”

88

8. A kérdőívek összefoglaló értékelése

8.

A kérdőívek összefoglaló értékelése A felmérés azt akarta megtudni, hogy Magyarországon a szoftverfejlesztői körökben milyen

mértékben vannak jelen a mintahasználatot feltételezhetően befolyásoló tényezők (lásd 2. tézis, 5.1. pont), és hogy mi a vélemény a kialakítás előtt álló SDP-city weblapról. A felmérést Internetes kérdőív segítségével végeztem el, az adatgyűjtés hólabda módszerrel történt. A kérdőívet összesen 109-en töltötték ki: 45 fejlesztő, 26 oktató, 29 tanuló és 9 menedzser. Az ezen felüli „kattintgatók”, az ún. outlyer-ek száma mindössze 4 volt. A 109 kitöltő kevésnek számít, figyelembe véve, hogy a kérdőív több ezer emberhez eljutott. Sajnos az Internetes felméréseknél számítani lehet az alacsony kitöltési arányra, erre a KSH és az MTA statisztikusai fel is hívták a figyelmemet. Csak kereszttáblás kimutatásokat végeztem; nem számítottam sem megbízhatóságot, sem korrelációt, sem regressziót. Az egyes tényezők közötti összefüggések vizsgálatának nincs értelme, mert egyrészt a mintavételi szám alacsony volt, másrészt a megjegyzésekből egyértelműen kiderül: a kitöltők többsége nincs tisztában a szoftverminta fogalmával. Ezt a tényt támasztja alá az is, hogy a válaszértékek szórása általában nagy. A mintahasználatot és az azt befolyásoló tényezőket az 5.1. ábra mutatja (45. oldal). A következő, 8.1. táblázat a felmérés eredményének összefoglaló táblázata. A 17. és 18. kérdést leszámítva a válaszértékek 1 és 7 közöttiek (a 17. kérdésre szöveges választ kellett adni, a 18a és 18b kérdésekre pedig a napok számát kellett megválaszolni). A megjegyzések magas száma és szövegezése mindenképpen a téma aktualitására és fontosságára utal. A mintahasználatra vonatkozó személyes kérdések

Szüksége van Önnek arra a tudásra, mellyel egy SDP-t el lehet készíteni? (10. kérdés) Milyen bonyolultságú szoftvert fejlesztett már? (11. kérdés)

Nem Átlag Szórás Fejl. Oktató Tanuló Mened. tud. 11 5.43 1.55 5.43 5.64 5.27 5.50 1

4.80

1.85

5.57

4.88

3.11

5.78

89

Angster Erzsébet: Doktori (PHD) értekezés, 2006

Szoftverminta használat

H1. Mintahasználat (12. kérdés) H2. Mintahasználat saját munkában (13. kérdés) H3. Mintahasználat csoportosan (14. kérdés) H4. Mintahasználat mintaírással (15. kérdés) Hány mintatárházat használ? (16. kérdés) Adja meg az Ön által használt fontosabb mintatárházakat! (17. kérdés, szöveges válasz) Egy évre vetítve hány munkanapot tölt el mintakereséssel, megértéssel vagy készítéssel? (18/a kérdés) Egy évre vetítve hány munkanapot takarít meg kész minták használatával? (18/b kérdés)

Nem tud. 2 2 3 4 3 –

Átlag Szórás Fejl. Oktató Tanuló Mened. 3.75 4.11 3.25 2.20 2.12 –

2.13 2.19 2.20 1.91 1.72 –

3.88 4.23 3.56 2.60 1.91 –

4.04 4.38 2.88 1.77 1.62 –

2.72 3.14 2.52 1.83 2.21 –

5.56 5.89 5.22 2.78 2.56 –

29

19.70 31.12 25.27

9.25

19.43

17.80

33

37.92 71.77 56.97 15.50

27.28

32.00

A mintahasználat terjedési környezete

B1. Újdonság foka (19-21. kérdések) B2. Innovatív szándék (22-23. kérdések) B3. A fejlesztő bevonása (24-26. kérdések) B4. Mintatárház (27-29. kérdések) B5. SDP-tárház (30-33. kérdések) B6. Élharcos (34-35. kérdések) B7. Véleményvezető (36-37. kérdések) B8. Változási ügynök (38-39. kérdések) B9. Oktatás (40-43. kérdések) B10. Tananyag (44-47. kérdések) B11. Bevezetett eljárás (48-50. kérdések) B12. Fórum (51-52. kérdések)

Nem tud. 4 3 3 3 3 5 3 3 3 3 3 3

Átlag Szórás Fejl. Oktató Tanuló Mened. 4.54 5.34 3.26 3.42 2.79 4.05 3.38 2.61 2.53 3.17 2.46 2.15

1.56 1.23 1.83 1.51 1.25 1.91 1.78 1.79 1.43 1.39 1.65 1.80

4.42 5.48 3.56 3.92 3.04 4.02 3.59 2.60 2.73 3.40 2.92 2.28

4.79 5.30 3.55 2.69 2.24 4.18 3.18 2.42 2.17 2.96 1.77 1.66

4.73 4.95 2.25 3.23 2.77 3.78 3.11 2.64 2.46 2.82 2.17 2.11

3.85 6.00 4.11 3.52 3.19 4.67 3.78 3.06 2.81 3.69 3.00 2.94

2 8 10 18 3 5

5.57 4.84 5.27 2.66 4.32 3.98

0.90 1.06 1.47 2.02 1.93 1.84

5.69 4.96 5.26 2.92 4.72 4.19

5.30 4.49 5.52 2.24 4.34 3.60

5.37 4.71 4.84 2.39 3.41 3.82

6.29 5.52 5.93 3.25 5.11 4.50

3 4

4.86 5.31

2.13 2.04

4.89 5.41

4.72 5.42

4.63 4.89

5.83 5.89

A mintahasználat érzékelt tulajdonságai B13. Hasznavehetőség (53-55. kérdések) B14. Könnyű használat (56-58. kérdések) B15. Kompatibilitás (59-60. kérdések) B16. Láthatóság (61. kérdés) B17. Eredmény felmutathatósága (62-63. kérdések) B18. Kipróbálhatóság (64-65. kérdések) A mintahasználat érzékelt hatásai B19. Érzékelt minőség (66-67. kérdések) B20. Érzékelt produktivitás (68. kérdés) SDP-city iránti igény

Szívesen használnám az SDP-city weboldalt. (69. kérdés) Szívesen kitennék én is az SDP-cityre saját fejlesztésű mintát vagy SDP-t. (70. kérdés) Mennyi pénzt kapjon az alkotó például egy zsűrizett Ingatlanközvetítő SDP-ért? (71. kérdés) Mennyi pénzt kapjon a pásztor egy zsűrizett terelgetésért (kb. 30 órai munkáért)? (72. kérdés)

90

Nem Átlag Szórás Fejl. Oktató Tanuló Mened. tud. 22 5.61 1.05 5.47 5.83 5.33 6.20 22

4.90

1.84

4.57

5.39

4.87

5.00

43

4.14

1.96

3.81

4.71

3.90

5.2

46

3.49

1.73

3.42

3.77

3.38

3.67

8. A kérdőívek összefoglaló értékelése Szívesen támogatnám (én vagy a szervezetem) a weboldalt a működés érdekében, évenként kb. ennyi euróval. (73. kérdés) Örülnék, ha a lapon levő minden alkotás nyílt dokumentációjú és forráskódú lenne. (74. kérdés) Tisztában vagyok a nyílt dokumentáció és forráskód fogalmával (open documentation, open source). (75. kérdés)

58

1.94

1.33

2.29

1.80

1.76

1.00

10

6.19

1.19

6.28

6.38

6.04

5.71

5

6.31

1.02

6.58

6.08

6.18

6.00

8.1. táblázat. A felmérés eredménye – összefoglaló táblázat

8.1.

Vélemény a kérdőívről

A kérdőívről az az általános vélemény, hogy a téma aktuális, a kérdések jól átgondoltak, de a kérdőív nagyon hosszú, kitöltése sok időt, gondolkodást igényel. Nyilvánvalóan ez volt az elsődleges oka a kitöltések alacsony számának.

8.2.

Szoftverminta használat (H1–H4)

A mintahasználattal kapcsolatos nem túl alacsony válaszértékek látszólag ellentmondásban vannak a megjegyzésekkel. A megjegyzésekből és a konkrét mintatárházak megadásából arra lehet következtetni, hogy a kitöltők nagy része félreértette a minta fogalmát, illetve még egyáltalán nem találkozott ezzel a fogalommal a szoftverfejlesztésben. Sokan mintának vették az ellenőrizetlen idegen kódrészleteket, a saját készítésű szoftverelemeket és az egyébként hasznos könyveket is (lásd 73. oldal, 17. kérdés kiértékelése). A félreértést bizonyítja az is, hogy a mintahasználatra vonatkozó Újdonság foka igen nagy (4.54), és a kitöltők mintegy fele (65-en) a „Hány mintatárházat használ” kérdésre nullával válaszolt. Annak ellenére, hogy a kitöltők mintának vették a nem szabályos mintákat is, a szoftverfejlesztői közösség még így is átlag alatt használ mintát (3.75). Leginkább a menedzserek vallják azt, hogy használnak mintákat (5.56); ezután az oktatók következnek (4.04), majd a fejlesztők (3.88), végül a tanulók (2.72). A mintahasználat főleg egyéni használatban merül ki (az egyéni mintahasználat átlag értéke 4.11), ami azt jelenti, hogy publikus mintákat használnak önálló fejlesztésekben. Csoportosan már kevesebben használnak mintát (ennek átlag értéke 3.25); mintát pedig nagyon kevesen írnak (2.20). A kitöltők úgy gondolják, hogy jelentős munkaidőt takarítanak meg a minták használatával (a ráfordított napok átlag száma évenként 19.70, a megtakarított napoké pedig 37.92).

91

Angster Erzsébet: Doktori (PHD) értekezés, 2006 8.3.

A mintahasználat terjedési környezete (B1–B12)

A mintahasználat terjedési környezetének tulajdonságaira a kitöltők határozottabb választ tudtak adni, mint az érzékelt tulajdonságokra. Itt aránylag kevés a „Nem tudom”-ok száma, ami érthető, mert mindenki tudhatja például, hogy kapott-e mintahaszálattal kapcsolatos oktatást, még akkor is, ha nem tudja, mi a minta. Megállapítható, hogy a mintahasználattal kapcsolatos újdonság foka nagy (4.54). A szoftverfejlesztők általában innovatívak (az innovatív szándék átlaga 5.34), de az embereket nem vonják be eléggé a mintakészítésbe (3.26). Nem áll rendelkezésre elegendő mintatárház (3.42) és nagyon kevés SDP-tárház van (2.79). Az élharcos jelenléte semleges (4.05), nem jellemző a véleményvezető jelenléte (3.38), a mintahasználat ügyében lobbizó változási ügynökökből pedig nagyon kevés van (2.61). Szoftvermintákkal kapcsolatos oktatás szinte nincs (2.53), és tananyag sincs elegendő (3.17). Nincsenek mintahasználattal kapcsolatos bevezetett eljárások (2.46), és szinte nincs fórum lehetőség a mintahasználtattal kapcsolatos problémák megbeszélésére (2.15). Az értékek elemzésénél itt is figyelembe kell venni, hogy a válaszolók a minta és az SDP fogalmát igazi jelentésüknél sokkal tágabb értelemben vették.

8.4.

A mintahasználat érzékelt tulajdonságai (B13–B18)

A mintahasználat érzékelt tulajdonságaival kapcsolatos kérdéseknél több a „Nem tudom”-ok száma, mint a terjedési környezettel kapcsolatos kérdésekben: aki még nem használt mintát, nem tudhatja, hogy könnyű-e használni, kompatibilis-e, látható-e stb. A táblázat mutatja, hogy a szoftverfejlesztői közösség nagyon hasznosnak érzékeli a mintahasználatot (5.57). Úgy gondolja, hogy aránylag könnyű használni (4.84), és hogy kompatibilis a munkájával (5.27), azonban a kitöltők nem nagyon látják a mintahasználatot (2.66). Úgy érzékelik, hogy a minta használatának következtében felmutatható némi eredmény (4.32). A kitöltők továbbá semlegesnek érzékelik a minták kipróbálhatóságát (3.98), ami vagy azt jelenti, hogy csak közepes mértékben van meg a lehetőségük a kipróbálásra, vagy azt, hogy a kitöltők nincsenek tisztában azzal, hogy kipróbálhatják-e a mintahasználatot.

92

8. A kérdőívek összefoglaló értékelése 8.5.

A mintahasználat érzékelt hatásai (B19–B20)

Az érzékelt minőség jóval nagyobb a semlegesnél (4.86), az érzékelt produktivitás pedig nagy (5.31). A kitöltők tehát úgy érzékelik, hogy a mintahasználattal munkájuk magasabb minőségű és termelékenyebb lesz.

8.6.

SDP-city iránti igény

A szoftverfejlesztési körökben határozott igény van az SDP-city weblapra (5.61). Azonban csak módjával tennének ki értékeket (4.90), és legkevesebbet pont a fejlesztők tennének ki (3.81), akik ezeket elsősorban képesek elkészíteni. A választ adók úgy gondolják, hogy egy átlagos alkotói munkáért kicsit több mint 100 euró jár, egy zsűrizett terelgetésért pedig kicsit kevesebb mint 100 euró (mindkét esetben az oktatók szerint több jár, a fejlesztők szerint kevesebb). A lapot az egyének és a cégek lényegében NEM támogatnák (1.94), még a fejlesztők adakoznának a legtöbbet (2.29). Annak szinte mindenki (de leginkább az oktatók) örülne, ha a lap nyílt dokumentációjú és forráskódú lenne (6.19). A kitöltők szerint a működési feltételek nagy vonalakban a következők: − Személyi feltételek: Szakmailag jól képzett, elhivatott pásztorok, és igényességre törekvő alkotók kellenek. − Szakmai feltételek: A gyakorlatban jól felhasználható problémák ismertetése; angol nyelvű változat (ne csak a magyar fejlesztők használhassák az oldalt). − Anyagi feltételek: Anyagi támogatás az alkotóknak és a pásztoroknak, valamint a honlapnak. A diplomamunkájukat készítő diákok fel fogják tenni az alkotásukat honorárium nélkül is. A gyakorlott alkotók és a pásztorok motivációja kérdéses. Az egyénektől és a cégektől nem várható támogatás, a laphoz állami segítség, illetve pályázati finanszírozás kell. − Jogi feltételek: Nagy igény van a nyílt dokumentáció és forráskódú szoftverekre. Sokan azt szeretnék, ha a felhasználás teljesen szabad lenne: az értékek legyenek ingyenesek, szabadon módosíthatók, és ne legyen kötelező a szerzőre való hivatkozás sem.

93

Angster Erzsébet: Doktori (PHD) értekezés, 2006

94

9. A mintahasználattal kapcsolatos tézisek

9.

A mintahasználattal kapcsolatos tézisek A kutatásban összegyűjtöttem a mintahasználatot befolyásoló tényezőket, majd felmértem,

hogy a szoftverfejlesztői körök (fejlesztők, oktatók, tanulók és menedzserek) használnak-e mintákat, és hogy a szóban forgó tényezők milyen mértékben vannak jelen. Ezután eredményeimet összehasonlítottam más kutatók eredményeivel. A mintahasználattal kapcsolatos téziseimet ezek alapján állapítottam meg.

9.1.

Nem használják a mintákat (3. tézis)

A magyar szoftverfejlesztői körökben (szoftverfejlesztők, oktatók, tanulók és menedzserek) lényegében nem használnak mintákat, vagyis a mintahasználat nem terjed. Ezt az eredményt Internetes felmérés segítségével mutattam ki (lásd 8.2. pont). Tudomásom szerint sehol a világon nem készült még széleskörű felmérés a szoftverminták használatáról.

9.2.

Az eredmények összevetése más kutatásokkal

A 9.1. táblázat összefoglalja, hogy négy – az innováció terjedésével foglalkozó – kutatásban milyen általam használt tényezők vannak jelen, és azok milyen hatással vannak az innováció terjedésére (használatára). A négy kutatás: DOI [Rogers, 1995], Egész termék [MooreGA, 1991], A fejlesztő bevonása és irányításérzékelése [Green et al., 1999], és A minták terjedését befolyásoló tényezők vizsgálata [Manns, 2002]. A „–” jelenti, hogy a tényezővel a megfelelő kutatás nem foglalkozik; a többi esetben a tényező jelen van a kutatásban, és ott pozitív, semleges vagy negatív hatással van az innováció terjedésére.

95

Angster Erzsébet: Doktori (PHD) értekezés, 2006 A tényező hatása az innováció/termék terjedésére Jelen kutatás tényezői B1. Újdonság foka B2. Innovatív szándék B3. A fejlesztő bevonása B4. (Minta)tárház B5. SDP-tárház B6. Élharcos B7. Véleményvezető B8. Változási ügynök B9. Oktatás B10. Tananyag B11. Bevezetett eljárás B12. Fórum

DOI [Rogers, 1995] – Pozitív – –

Egész termék [MooreGA, 1991] – – – 21

Pozitív

23

– Pozitív Pozitív Pozitív – –

Pozitív – – – Pozitív

24

Pozitív

25

–

Pozitív 29

22

Pozitív

22

Pozitív Pozitív – – Pozitív –

26

Pozitív Pozitív Pozitív Pozitív –

Pozitív

Pozitív

– –

Pozitív –

Pozitív Pozitív Pozitív Pozitív Pozitív

Pozitív

B14. Könnyű használat B15. Kompatibilitás

Pozitív Pozitív

B16. Láthatóság B17. Eredmény felmutathatósága B18. Kipróbálhatóság

Pozitív Pozitív Pozitív

– – –

– – –

B19. Érzékelt minőség B20. Érzékelt produktivitás

– –

– –

Pozitív Pozitív

31

Pozitív –

Pozitív

Pozitív –

B13. Hasznavehetőség

30

Mintahasználat [Manns, 2002] – Pozitív –

Pozitív –

27

–

A fejlesztő bevonása [Green et al. 1999] Semleges – Pozitív

32

Negatív 28

– –

9.1. táblázat. A vizsgált tényezők hatásai az innováció terjedésére – összehasonlítás A DOI kutatásból [Rogers, 1995] kutatásából átvettem a szociális rendszerre vonatkozó egyik idő tényezőt (B2) és az összes szerepkör tényezőt (B6–B8), valamint átvettem az innováció tulajdonságaira vonatkozó összes tényezőt (B13–B18). A Hasznavehetőség a DOI-ban

21 22 23 24 25 26 27 28 29 30 31 32

A tárház az Egész termék elméletben Támogatás néven, FowlerP [1995] kutatásában Eszköztámogatás néven van jelen. Csak mint tárház értendő. A tárház itt eszköztámogatás néven szerepel, hatását a PSP-re Green et al. nem bizonyította. A Mintatárház és az SDP-tárház tárházak. Az Egész termék elméletben a különböző tárházak pozitív hatással vannak az innováció terjedésére. A Tananyag mint dokukumentáció értendő. Az Egész termék elméletben a termékhez tartozó dokumentáció pozitív hatással van az innováció terjedésére. A Bevezetett eljárás vagy Szabvány FowlerP [szerint] az Egész termék kelléke. Az Érzékelt irányításon belül a Folyamat tényező ellentéte. A Fórum mint támogatás értendő. Mannsnál a Fórum csak a láthatósághoz tartozó műveleti ajánlásnál szerepel. A Hasznavehetőség a DOI-ben Relatív előny néven szerepel. A Könnyű használat a DOI-ban Bonyolultság néven szerepel. A Láthatóság és az Eredmény felmutathatósága a DOI-ban együtt Megfigyelhetőség néven szerepel. Az érzékelt minőség és érzékelt produktivitás hatását a PSP-re Green et al. nem bizonyította.

96

9. A mintahasználattal kapcsolatos tézisek Relatív előny néven szerepel; a Könnyű használat Bonyolultság néven, a Láthatóság és az Eredmény felmutathatósága a DOI-ban együtt Megfigyelhetőség néven szerepel. Rogers szerint e tényezők mindegyike pozitív hatással van az innováció terjedésére (lásd 4.1., Az innováció terjedése). Az „Egész termék elmélet” [MooreGA, 1991] szerint az innováció, illetve termék terjedésére határozottan pozitív hatással van az oktatás, a dokumentáció és a támogatás. Fowler és Manns [FowlerP, 1995; Manns, 2002] az egész termékeket az oktatás, bevezetett eljárások, és eszköztámogatások (pl. tárházak) kategóriákba sorolta. A tárház az Egész termék elméletben Támogatás néven, Fowler kutatásában Eszköztámogatás néven van jelen. A Bevezetett eljárás Fowler szerint szintén az Egész termék kelléke mint támogatás. Az általam használt tényezők közül az Egész termék elméletben megtalálható az Oktatás; a Tananyag mint dokumentáció; valamint az SDP-tárház, a Mintatárház, a Bevezetett eljárás és a Fórum mint támogatás. E tényezők mindegyike pozitív hatással van a termék terjedésére (lásd 4.2., Egész termék). „A fejlesztő bevonása és irányításérzékelése” kutatásában Green et al. [1999] kimutatta, hogy a szoftverfejlesztési technika terjedési sikerére pozitív hatással van a Fejlesztő bevonása és a terjedési környezet tulajdonságai, mint az Eszköztámogatás, Élharcos támogatás és Oktatás. Az Újdonság foka tényező hatását Green et al. semlegesnek találta az innováció terjedésében. Az Eszköztámogatás jelen kutatásban tárházak formájában van jelen (SDPtárház és Mintatárház, lásd 4.2., Egész termék). Az irányításérzékelés Eljárás (Process) komponense Green at al. szerint negatív hatású, de ez pont azt jelenti, hogy a Bevezetett eljárás hatása pozitív (lásd 4.4., A fejlesztő bevonása és irányításérzékelése). A fejlesztő által érzékelt IT tulajdonságok, mint a Könnyű használat és a Hasznavehetőség, valamint az fejlesztő által érzékelt hatások, mint az Érzékelt minőség és Érzékelt produktivitás Green et al. szerint közvetítő szerepet játszanak a terjedés sikerességében (a használatban és a megelégedettségben), így ezek is pozitív hatásúak. „Mintahasználat” kutatásában Manns [2002] kimutatta, hogy a következő tényezők pozitív hatással vannak a mintahasználatra: Innovatív szándék, Mintatárház, Élharcos, Véleményvezető, Változási ügynök, Oktatás, Hasznavehetőség, Könnyű használat, Kompatibilitás, Láthatóság, Eredmény felmutathatósága, Kipróbálhatóság. A Bevezetett eljárás tényező hatása viszont negatív. Vagyis Manns szerint a fejlesztők nem szeretik, ha szabványokkal és eljárásokkal megkötik a kezüket a mintahasználat során. Fontos azonban megjegyezni, hogy Manns

97

Angster Erzsébet: Doktori (PHD) értekezés, 2006 célközönsége gyakorlott fejlesztők. Mannsnál ugyan nincs Fórum tényező, de hetedik ajánlása szerint: „OG7: Egy szervezetnek effektív módokat kell találnia ahhoz, hogy a mintákat láthatóvá tegye mindenféle presszionálás és hiperaktív marketing nélkül”. Manns a láthatóvá tételnek tíz lehetséges módját adja meg, ezek közül egy az e-Fórum (lásd 4.5., A minták terjedését befolyásoló tényezők vizsgálata A minták terjedését befolyásoló tényezők vizsgálata ). Mivel jelen kutatás Mannshoz hasonlóan konkrétan a mintahasználat mint innováció terjedését befolyásoló tényezőket vizsgálja, eredményeimet összehasonlítom Manns eredményeivel. A 9.2. táblázat mutatja a mintahasználatot befolyásoló tényezőket és azok átlagértékeit a két felmérésben. A két mintavétel közötti alapvető különbség, hogy − Manns egy zárt szakmai kört kérdezett meg az USÁ-ban, és a felmérés célja a mintahasználatot befolyásoló tényezők összegyűjtése volt; − jelen felmérés pedig megcélozta a teljes szakmai közösséget Magyarországon, és a felmérés célja az egyes tényezők konkrét értékének megállapítása. Látható, hogy a legtöbb tényező esetén az eltérés mértéke kicsi. Az egyes tényezőkhöz tartozó magyarázatokat a táblázat tartalmazza. Manns kutatási célja nem az átlagértékek vizsgálata, hanem a tényezők közötti összefüggések megállapítása volt: azon tényezők meghatározása, amelyek legjobban befolyásolják a mintahasználatot. Manns két kutatási kérdése és az azokra adott válaszok a következők: − Manns 1. kutatási kérdése: Mely faktorok vannak hatással a mintahasználatra a szervezetekben dolgozók között? A kérdést Manns egy kérdőív segítségével mérte fel, és a következő eredményre jutott: Hasznavehetőség, Eredmény felmutathatósága, Láthatóság, Kompatibilitás, Mintatárház, Kipróbálhatóság, Bevezetett eljárás, Innovatív szándék, Véleményvezető. Ezek közül a Bevezetett eljárás hatása negatív, a többié pozitív. − Manns 2. kutatási kérdése: Mely faktorokat tartják fontosnak a mintahasználat érdekében a szervezetekbe mintát bevezető egyének? A kérdést Manns egy szerepjátékkal mérte fel, melyben a résztvevők a következő faktorokat határozták meg: Oktatás, Láthatóság, Véleményvezető, Kompatibilitás, Kipróbálhatóság. A következő faktorokat a résztvevők nem tartották fontosnak a mintahasználat szempontjából: Bevezetett eljárás, Könnyű használat, Innovatív szándék (és Imázs). 98

9. A mintahasználattal kapcsolatos tézisek

B1. Újdonság foka B2. Innovatív szándék B3. A fejlesztő bevonása B4. Mintatárház

Manns Angster Eltérés Magyarázat (Angster -Manns) – 4.54 – Csak Angster méri. Ott a kitöltők számára a mintahasználat új. Manns ezt nem méri, mert az általa megcélzott körben a mintahasználat mindenkinek ismerős fogalom. 5.4 5.34 -0.06 A kitöltők mindkét mérésben egyformán innovatívak. –

3.26

–

2.7

3.42

0.72

–

2.79

–

B6. Élharcos

4.2

4.05

-0.15

B7. Véleményvezető

4.9

3.38

-1.52

B8. Változási ügynök B9. Oktatás

3.3

2.61

-0.69

3.3

2.53

-0.77

B10. Tananyag

–

3.17

–

B11. Bevezetett eljárás B12. Fórum B13.Hasznavehetőség

4.3

2.46

-1.84

– 5.9

2.15 5.57

– -0.33

B14. Könnyű használat B15. Kompatibilitás

4.8

4.84

0.04

6.0

5.27

-0.73

B16. Láthatóság

3.5

2.66

-0.84

B17. Eredmény felmutathatósága

5.7

4.32

-1.38

B18. Kipróbálhatóság

3.9

3.98

0.08

B19. Érzékelt minőség

–

4.86

–

B20. Érzékelt produktivitás

–

5.31

–

B5. SDP-tárház

Csak Angster méri. Ott a fejlesztőket átlagon alul vonják be a mintahasználatba. Mannsnál ez az érték alacsonyabb, mint Angsternél. Az elemzés szerint ennek oka, hogy Angster kitöltőivel ellentétben Manns kitöltői tudják, mit jelent a mintatárház. Csak Angster méri. Ott erősen átlag alatt használnak SDPtárházat. Nagyon kicsi az eltérés: Mindkét mérésben jelen van az élharcos, de csak „módjával”. Manns mérésében sokkal magasabb értékű a véleményvezető jelenléte: ott sokkal több a mintát ismerő és értő szakember. Itt az eltérés nagyobb, mint az élharcosnál, de egyik helyen sincs jelen igazán a változási ügynök. Nagyon alacsony mindkét mérésben. Egyik helyen sincs jelen igazán az oktatás. Manns kitöltői azonban lényegesen több oktatást kapnak. Csak Angster méri. A mintahasználattal kapcsolatos tananyag jóval átlagon aluli. Az eltérés nagyon nagy. Manns kitöltői körében sokkal jellemzőbb, hogy egy megadott eljárás szerint használják a mintákat. Csak Angster méri, ott nagyon alacsony értékkel van jelen. Az eltérés kicsi. Mindkét mérésben a kitöltők úgy érzik, hogy a mintahasználat hasznukra válik. A kitöltők egyformán úgy érzik, hogy a minta használata aránylag könnyű (az érték nem túl magas). A kitöltők úgy érzik (főleg Mannsnál), hogy a mintahasználat kompatíbilis a munkájukkal. A kitöltők egyik mérésben sem látják a mintahasználatot. Angster kitöltői még sokkal kevésbé látják. Angsternél sokkal alacsonyabb az eredmény. Ez érthető, mert ott a kitöltők nem nagyon használnak mintákat, ezért nem is mutathatnak fel eredményt. A kitöltők egyformán semlegesnek érzik a minta használatának kipróbálhatóságát. Csak Angster méri. A kitöltők úgy érzik, hogy a mintahasználattal a termék minősége jobb lesz, illetve lenne. Csak Angster méri. A kitöltők úgy érzik, hogy a mintahasználattal produktívabbak lesznek, illetve lennének.

9.2. táblázat. A tényezők átlag értékei – összevetés Manns eredményével Manns kutatását így összegzi [Manns, 2002, 81. oldal]: „A kitöltők többsége technikai munkatárs. Legtöbbjüknek nem új a minta fogalma. Főként saját munkájukban használnak mintákat. Magukat innovatívnak érzik és úgy gondolják, hogy a minták kompatibilisek munkájukkal. Tudatában vannak a mintahasználat relatív előnyeivel (hasznavehetőségével) és eredményeivel. Többségük 99

Angster Erzsébet: Doktori (PHD) értekezés, 2006 olyan szervezetből jött, ahol a mintahasználat önkéntes, de nem látható. A legtöbb szervezetnek nincs mintatárháza, nincs változási ügynök és nincs mintával kapcsolatos oktatás.” Képezzük a Manns két kutatási eredményében szereplő tényezőhalmaz unióját! Ez a tényezőhalmaz csak az Oktatással bővebb, mint az első tényezőhalmaz. Vonjuk ki ebből az únióból azokat a tényezőket, amelyeket a második kutatás szerint az egyének nem tartottak fontosnak! A 9.3. táblázat tartalmazza a megmaradt tényezőket, és azoknak a két kutatásban felmért átlagértékeit – az Angster által mért átlagértékek emelkedő sorrendjében. Látható, hogy a Manns által nagyhatásúnak mért tényezők között vannak olyanok, amelyek nagyon alacsony étékkel vannak jelen, különösen a jelen felmérésben: ezek az Oktatás, a Láthatóság, a Véleményvezető és a Mintatárház. Ezek szerint a potenciális mintahasználók nem kapnak megfelelő oktatást, nem „látják” a mintákat, nincs véleményvezetőjük, és nincs könnyen elérhető mintatárházuk. Az Oktatás és a Láthatóság mindkét kutatásban alacsony értékű (az átlag 3 körül van). A Véleményvezető Manns mérésében sokkal inkább jelen van, de ott sem elegendően magas az érték. Manns 8. ajánlásában (OG8) szorgalmazza is a véleményvezetők jelenlétét. A Mintatárház érdekes módon Mannsnál jóval alacsonyabb értékű, mint Angsternél. Az elemzés szerint ennek oka, hogy Angster kitöltőivel ellentétben Manns kitöltői tudják, mit jelent a mintatárház. A Kipróbálhatóság egyik mérésben sem kielégítő, hiszen ezek értéke is semleges, vagyis a kitöltők nem igazán tudják kipróbálni a mintahasználatot. Az Eredmény felmutathatósága Manns mérésében elég magas értékű (5.7), de Angster mérésében ezzel is probléma van, hiszen a kitöltők számára a tényező majdnem közömbös. A Kompatibilitás és a Hasznavehetőség mindkét felmérésben magas értékkel van jelen. Angster 2.53

Manns 3.3

B16. Láthatóság

2.66

3.5

B7.

Véleményvezető

3.38

4.9

B4.

Mintatárház

3.42

2.7

B18. Kipróbálhatóság

3.98

3.9

B17. Eredmény felmutathatósága

4.32

5.7

B15. Kompatibilitás

5.27

6.0

B13. Hasznavehetőség

5.57

5.9

B9.

Oktatás

9.3. táblázat. Manns legnagyobb hatású tényezőinek értékei a két kutatásban

100

9. A mintahasználattal kapcsolatos tézisek Ebben a kutatásban van még három további tényező jelölt, amelyek feltételezhetően befolyásolják a mintahasználatot: az SDP-tárház, a Tananyag és a Fórum. A 9.4. táblázat mutatja, hogy ezen tényezők értékei szintén rendkívül alacsonyak.

B12. Fórum B5.

SDP-tárház

B10. Tananyag

Angster 2.15 2.79 3.17

9.4. táblázat. Angster feltételezett nagy hatású tényezőinek értékei A fentiekből következik, hogy nincsenek meg a mintahasználat terjedésének tárgyi és személyi feltételei. A fenti értékelésre alapozva a következőket állítom (4. és 5. tézis):

9.3.

Alacsonyak a mintahasználatot pozitívan befolyásoló tényezők értékei (4. tézis)

A mintahasználatot mint innovációt más szerzők szerint pozitívan befolyásoló tényezők túlnyomó többsége nagyon alacsony értékkel vannak jelen Magyarországon. A következő tényezők átlag alatti értékűek – növekvő sorrendben: Oktatás, Láthatóság, Véleményvezető, Mintatárház és Kipróbálhatóság. A mintahasználat lényegesen jobban terjedne, ha ezek a tényezők nagyobb értékkel lennének jelen a szoftverfejlesztői körökben. Ajánlás: A fenti tényezők értékeit növelni kell. Vagyis: -

A mintákat oktatni kell;

-

A mintákat láthatóvá kell tenni;

-

A cégeknél és az iskolákban kellenek véleményvezetők, akik véleményükkel erős hatást gyakorolnak társaikra, s ezzel segítik őket a döntésben;

-

Szükség van elérhető mintatárházra;

-

Lehetővé kell tenni, hogy a fejlesztők, oktatók, tanulók és menedzserek a szoftvermintákat kipróbálhassák.

101

Angster Erzsébet: Doktori (PHD) értekezés, 2006 9.4.

Nincs fórum, SDP-tárház és tananyag (5. tézis)

Nagyon alacsony értékkel vannak jelen Magyarországon a következő tényezők: Fórum, SDP-tárház és Tananyag. Más kutatási eredményekre alapozva (Egész termék [MooreGA, 1991], Szoftverfejlesztési innováció [Attewell, 1992], A fejlesztő bevonása és irányításérzékelése [Green et al., 1999]) ezek a tényezők feltételezhetően további hatással lennének a mintahasználatra. Ajánlás: Feltételezhetően szükség van -

fórum-lehetőségekre;

-

SDP tárházra; és

-

több tananyagra.

Az utóbbi három tényezőnek a mintahasználatra történő hatását ez a dolgozat nem mérte fel.

102

10. Innovációs modell: SDP keretrendszer

10. Innovációs modell: SDP keretrendszer ”We must reverse the decline in the quality of developer training.”33 [McBreen, 2002] „Discovery is to see what everyone else has seen, and to think what no one else has thought.” 34 Szent-Györgyi Albert

10.1. Az SDP keretrendszer felállítása (6. tézis) A kutatás eredményeképpen kidolgoztam egy innovációs modellt – az SDP keretrendszert –, melynek célja, hogy elősegítse a mintahasználat terjedését a szoftverfejlesztők, oktatók, tanulók és menedzserek körében (egyénileg, csoportosan vagy mintaírással), és ezáltal kísérletet tegyen az „ördögi kör” feloldására [Angster, 2004c].

Az SDP keretrendszer egy szervezet és tárház, amely a szoftverminták használatának terjedésével a szoftverfejlesztés minőségének javítását, valamint az oktatási/tanulási folyamat elősegítését tűzi ki célul. Az SDP keretrendszer tulajdonságait a kutatás eredményének megfelelően alakítottam ki, vagyis a kutatásban feltárt, a mintahasználatot befolyásoló tényezők magas értékkel vannak jelen: az SDP keretrendszer tartalmaz szoftverminta-oktatást, a minták láthatók, van benne véleményvezető, mintatárház, SDP-tárház, fórum stb. A keretrendszer bevonja a mintahasználókat (fejlesztőket, oktatókat, tanulókat és menedzsereket) a keretrend-

33 34

Vissza kell fordítanunk a fejlesztők minőségi oktatásának hanyatlását. Felfedezni annyit jelent: látni, amit mindenki lát, és gondolni, amit még senki sem gondolt.

103

Angster Erzsébet: Doktori (PHD) értekezés, 2006 szer építésébe azáltal, hogy ők maguk készítik, pásztorolják és oktatják az alkotásokat (mintákat, SDP-ket, tananyagokat). Az SDP keretrendszer − lehetőséget ad szoftverfejlesztési alkotások (SDP-k, szoftverminták és tananyagok), valamint cikkek tárolására és visszakeresésére; − van benne oktatás és műhelymunka; − otthont ad különböző fórumoknak (vélemény-nyilvánítás, cikkek, e-fórum, felmérések stb.) Az SDP-city törekszik arra, hogy tárházában minél több minőségi alkotás szerepeljen, ezért az alkotásokat szakemberek segítik és minősítik. Kérésre az alkotó kap egy pásztort, aki az alkotót addig „terelgeti”, amíg az alkotás megfelelő, „pásztorolt” színvonalú nem lesz. A minőség szerint szűrt alkotások között sokkal hatékonyabb a keresés. A keretrendszerben a minőséget a zsűri garantálja azáltal, hogy megválogatja a pásztorokat; az alkotások minőségét pedig a pásztorok garantálják. Az SDP keretrendszer egy példánya az SDP-city: http://sdp-city.hu. Az „SDP-city” SDP megtalálható az SDP-city SDP-tárházában.

10.2. A mintahasználatot befolyásoló tényezők az SDP keretrendszerben Az SDP keretrendszert úgy alakítottam ki, hogy minél több olyan tulajdonsággal rendelkezzen, amelyek pozitívan hatnak a minta használatára. Az SDP keretrendszer – a mintához hasonlóan – egy szoftverfejlesztési innováció, továbbá a mintahasználat az SDP keretrendszer használatának része. Ezért feltételezhető, hogy a mintahasználatot befolyásoló tényezők az SDP keretrendszer használatára is hatással lesznek. Az SDP keretrendszer modelljében Green et al. [1999] modelljéhez hasonlóan külön vettem a terjedési környezet tulajdonságait, az érzékelt tulajdonságokat és az érzékelt hatásokat (10.1. ábra). Az ábrán a nyilak mutatják a tényezők feltételezhető egymásra hatását. Az egyes csoportokban a mintahasználatot befolyásoló tényezőket (az SDP keretrendszer tulajdonságait) a 9.3. és 9.4. táblázatok figyelembe vételével határoztam meg. A számozott elemek (Ei, Ti) az SDP keretrendszer feltételezhetően nagyhatású tényezőit mutatják, a számozatlan elemek pedig a kevésbé nagyhatásúakat. A következő pontok részletesen tárgyalják az egyes tényező-csoportokat.

104

10. Innovációs modell: SDP keretrendszer

A mintahasználat érzékelt tulajdonságai E1. Láthatóság E2. Kipróbálhatóság E3. Eredmény felmutathatósága E4. Kompatibilitás E5. Hasznavehetőség A mintahasználat terjedési környezete T1. Oktatás T2. Véleményvezető T3. Mintatárház T4. Fórum T5. SDP tárház T6. Tananyag Újdonság foka Innovatív szándék A fejlesztő bevonása Élharcos Változási ügynök Bevezetett eljárás

Könnyű használat

Mintahasználat az SDP keretrendszerben H1. Mintahasználat H2. Mintahasználat saját munkában H3. Mintahasználat csoportosan H4. Mintahasználat mintaírással

A mintahasználat érzékelt hatásai Érzékelt minőség Érzékelt produktivitás

10.1. ábra. A mintahasználatot befolyásoló tényezők az SDP keretrendszerben

10.3. A mintahasználat terjedési környezetének tulajdonságai az SDP keretrendszerben Az SDP keretrendszerben különös figyelmet kell fordítani a mintahasználat terjedési környezetének azon tulajdonságaira, amelyek a kutatási eredmény szerint feltételezhetően nagy hatással vannak a mintahasználat terjedésére. Ezek a következők: (T1)

Oktatás: Az SDP keretrendszerben van oktatás. Az elméleti oktatást műhelymunkákkal is alá kell támasztani. Ajánlatos, hogy a keretrendszerben csak pásztorok oktathassanak, mert így könnyebb biztosítani a minőséget és az elmélet gyakorlattal való alátámasztását.

105

Angster Erzsébet: Doktori (PHD) értekezés, 2006 (T2)

Véleményvezető: Az SDP keretrendszerben vannak véleményvezetők. Ezek elsősorban a zsűritagok és a pásztorok, de véleményvezető lehet bárki, aki véleményével hozzájárul a keretrendszer működéséhez – például a keretrendszer valamely fórumán keresztül.

(T3)

Mintatárház: Az SDP keretrendszerben van mintatárház. A már bevált, jó megoldásokat az oktatásba és a mindennapi használatba is be kell „emelni”, azaz lehetőleg mintákból kell építkezni. Az SDP keretrendszernek vannak ajánlott mintái. Ajánlatos, hogy az SDP-k elsősorban ezekből a mintákból építkezzenek.

(T4)

Fórum: Az SDP keretrendszerben vannak az alkotásokhoz tartozó véleménynyilvánítások, cikkek, e-fórumok és felmérések. Ezek lehetőséget adnak arra, hogy a fejlesztők, oktatók, tanulók és menedzserek kinyilváníthassák és megvitathassák aktuális témáikat, problémáikat. A fórum segítségével a keretrendszernek folyamatos visszajelzést kell kapnia a tizenegy tényezőről.

(T5)

SDP-tárház: A keretrendszerben vannak SDP-k. Az elmélet (így a minta is) sokkal érthetőbb, ha van mögötte futó alkalmazás.

(T6)

Tananyag: Az SDP keretrendszerben vannak tananyagok. Ajánlatos, hogy az egyes alkotásokhoz tananyagok tartozzanak, továbbá hogy a tananyagok gyakorlati példái a keretrendszer SDP-iből legyenek kiválasztva.

A fenti tényezőkön kívül természetesen jelen lesznek további, a mintahasználatot pozitívan befolyásoló tényezők is: − Újdonság foka: Az SDP keretrendszer megvalósításával a szoftverfejlesztői körökben kevésbé lesz újdonság a minta; − Innovatív szándék: A keretrendszert használók feltehetően innovatív szándékúak lesznek, mivel az alkotások készítéséhez és használatához ez mindenképpen szükséges. − A fejlesztő bevonása: A fejlesztő bevonása szerves eleme a keretrendszernek, hiszen a fejlesztő maga készíti a mintákat és az SDP-ket, és véleményével is jelentősen hozzájárulhat a rendszer kialakításához. − Élharcos: A zsűri személyesen hat a pásztorokra, a pásztor pedig az alkotóra, ezzel előmozdítja, reklámozza a minták használatát. 106

10. Innovációs modell: SDP keretrendszer − Változási ügynök: Megpróbálja pozitívan befolyásolni kifelé is a mintahasználatot, és további „híveket” szerezni a keretrendszer használatához. A zsűri mindenképpen vállalni fog ilyen szerepkört. − Bevezetett eljárás: A minták és SDP-k bevezetett eljárás szerint fognak készülni. Az alkotást pásztor segíti, és megadott szabályok szerint lehet csak betenni a tárházba. 10.4. A mintahasználat érzékelt tulajdonságai az SDP keretrendszerben A szoftverfejlesztési innováció érzékelt tulajdonságait befolyásolják a terjedési környezet tulajdonságai, és az érzékelt tulajdonságok további hatással vannak az innováció terjedésére [Green et al., 1999]. Az SDP keretrendszerben a mintahasználat érzékelt tulajdonságairól folyamatos visszajelzést kell kapni a fórum különböző formáinak segítségével (véleménynyilvánítások, cikkek, e-fórumok és felmérések), és ez alapján javítani kell a mintahasználat terjedési környezetének tulajdonságait. A mintahasználat érzékelt tulajdonságai az SDP keretrendszerben a következők: (E1)

Láthatóság: Fontos, hogy az SDP keretrendszerben a minták láthatóak legyenek. Aki látja a keretrendszert, az látja benne a mintákat is, mert a mintatárház a keretrendszer szerves része. Ajánlatos, hogy a minták és a hozzá tartozó SDP-k korlátozás nélkül letölthetők és használhatók legyenek.

(E2)

Kipróbálhatóság: Az SDP keretrendszerben fontos, hogy a minták kipróbálhatók legyenek. A kipróbálást az teszi lehetővé, hogy a minták egész termékek, vagyis tartozik hozzá oktatás, dokumentáció és támogatás, és ezeket könnyű elérni.

(E3)

Eredmény felmutathatósága: Törekedni kell arra, hogy az SDP keretrendszerben a minták használatával az eredmény felmutatható legyen. Felmutatható eredmény például a mérhető (nem érzékelt!) minőségi javulás vagy a nagyobb produktivitás (időmegtakarítás).

(E4)

Kompatibilitás: Aez SDP keretrendszerben a mintáknak kompatibiliseknek kell lenniük a fejlesztők, oktatók, tanulók és menedzserek munkájával. Törekedni kell arra, hogy a keretrendszerbe olyan minták kerüljenek, amelyeket az emberek kompatibilisnek éreznek

107

Angster Erzsébet: Doktori (PHD) értekezés, 2006 (E5)

Hasznavehetőség: Fontos, hogy a keretrendszerbe olyan minták kerüljenek, amelyeket az emberek hasznosnak éreznek.

A fenti tényezőkön kívül a kevésbé kritikus tényezőknek is jelen kell lenniük: − Könnyű használat: Ide tartozik például a kereshetőség és az egyes alkotások (minták, SDP-k) áttekinthetősége. A lehető legtöbb keresési lehetőséget meg kell adni. Keresni lehet az alkotások tulajdonságára. Mivel az alkotások szűrtek (csak ellenőrzött, pásztorolt alkotások kerülhetnek be a keretrendszerbe) a keresés így nagyon hatékony lehet. 10.5. A mintahasználat érzékelt hatásai az SDP keretrendszerben A mintahasználat érzékelt hatásai a terjedési környezet következményei. Ezek a tulajdonságok azonban a kutatási eredmény szerint feltételezhetően további nagy hatással vannak a mintahasználat terjedésére. Az érzékelt hatásokat az SDP keretrendszernek figyelnie kell, és szükség esetén javítani kell a terjedési környezet tulajdonságait. Az érzékelt hatásokról a keretrendszernek folyamatos visszajelzést kell kapnia a fórum különböző formáinak segítségével (vélemény-nyilvánítások, cikkek, e-fórumok és felmérések). Az érzékelt hatások tényezőinek hatása a mintahasználatra egyelőre nem bizonyított, de ajánlatos, hogy ezek is jelen legyenek: − Érzékelt minőség: A mintahasználók remélhetőleg úgy fogják érezni, hogy magasabb lesz a minták és SDP-k minősége. A minőséget az SDP keretrendszer ellenőrzéssel, szakmai koordinálással éri el. Minden alkotó kap egy szakmai pásztort, aki terelgetéssel segíti javítani az alkotás szakmai színvonalát. Az alkotásnak a keretrendszerbe történő bekerüléséről a pásztor dönt. − Érzékelt produktivitás: A mintahasználók remélhetőleg úgy fogják érezni, hogy megnőtt a termelékenységük a szoftverfejlesztésben. Az SDP keretrendszerrel egy olyan logikai-pedagógiai rendszert alkottam, amely messzemenően figyelembe veszi a szoftverfejlesztést tanuló és oktató igényeit, és piacképes tudást biztosít a szoftverfejlesztői kör számára. A kidolgozott rendszer általánosítható: a szoftverfejlesztésen kívül számos más szakterületen alkalmazható akár pedagógiai, akár fejlesztési célra.

108

10. Innovációs modell: SDP keretrendszer 10.6. Tervek, tervezett kutatások Az SDP-city lap (http://sdp-city.hu) fejlesztés alatt áll. A fejlesztőcsapat egyelőre két fős: Angster Erzsébet és Dr. Medzihradszky Dénes. A kifejlesztett modulokat folyamatosan implementáljuk, és betesszük az SDP-city SDP tárházába. Ajánlott minták már találhatók a lapon, és folyamatban van több SDP fejlesztése, amelyekből néhányat terveink szerint még 2006-ban beteszünk az SDP tárházba. Ezután várhatóan beindul majd az SDP „termelés”. A pásztorok száma pillanatnyilag 6. 2009-ban tervezek egy újabb felmérést az SDP-city működéséről és a mintahasználatról. A felmérésben a mintahasználatot befolyásoló tényezők ugyanezek lesznek, de a kérdések száma tényezőnként csak egy lesz. A 2004-es és a 2009-as felmérés között a legnagyobb különbség az lesz, hogy a kitöltők feltételezhetően már tisztában lesznek a szoftverminta fogalmával.

Úgy tűnik, hogy az SDP-k készítése óriási munka. Több kísérletet tettem arra, hogy egy-egy hallgatóval, szoftverfejlesztővel célba érjek – sajnos az eddigi kísérleteim nem sikerültek. Pedig többször elindítottam különböző „workshopokat” tehetséges és lelkes hallgatókkal, és amelyekbe bevontam nagyobb cégek fejlesztőit is (ez csak baráti alapon ment). A feloszlás indoka mindig az időhiány volt; a résztvevőket betemette a munkahelyi elfoglaltság. További probléma, hogy mivel senkinek sincs jó fejlesztési „mintája”, a munka nagy. Remélem azonban, hogy ha egyszer „megtörik a jég”, akkor ez a lap óriási segítség lesz a szoftverfejlesztői körök számára. A felmérés szerint a lapra nagy szükség van a szoftverfejlesztői körökben.

109

Angster Erzsébet: Doktori (PHD) értekezés, 2006

110

11. Felmérés a mintahasználat hasznosságának bemutatására

11. Felmérés a mintahasználat hasznosságának bemutatására Ebben a fejezetben a mintahasználatot mutatom be egy felmérésen keresztül. Egy kísérletet végeztem, hogy a szakterületi modellezést mennyire segíti Fowler [1997] elemzési (analízis, szakterületi) mintáinak ismerete. A modellezési feladat egy hallgatói diplomamunka keretében készülő konkrét szoftverfejlesztési projektből való (a megrendelő nevét megváltoztattam). A kísérletben összesen 6 oktató (2 egyetemi és 4 főiskolai), 2 fejlesztő és 2 hallgató vett részt, akiknek egy nagyvonalú feladatleírás alapján egy szakterületi (elemzési) modellt kellett felállítaniuk. Előzőleg senki nem ismert semmilyen elemzési mintát. A feladat a Felelősség elemzési mintacsoporthoz illeszkedik [Fowler, 1997], melynek mintái: Szereplő (Party), Szervezeti hierarchiák (Organization Hierarchies), Szervezeti struktúra (Organization Structure), Felelősség (Accountability), Ismereti szintű felelősség (Accountability Knowledge Level), Szereplőtípus leszármazottak (Party Type Generalizations), Hierarchikus felelősség (Hierarchic Accountability), Működési körök (Operating Scopes) és Pozíció (Post). A kísérletben résztvevők a Felelősség mintacsoportról készült tananyagot a kísérlet megadott fázisában megkapták, magyar nyelven [Angster, 2005b]. A kísérletben résztvevők a beadott modelleket az UML szabványos modellezési nyelven készítették el. A résztvevőket két csoportra osztottam: − Az első csoport (3 oktató, 1 fejlesztő és 1 hallgató) két menetben dolgozott: először az elemzési minták ismerete nélkül felállították az „A” modellt. Ezután átadtam részükre a felelősség mintákról szóló tananyagot [Angster, 2005b], majd munkájuk átdolgozásával elkészítették a „B” modellt. − A második csoport tagjai (további 3 oktató, 1 fejlesztő és 1 hallgató) rögtön megkapták a vonatkozó elemzési mintákat, és azok ismeretében készítették el a „C” modellt.

111

Angster Erzsébet: Doktori (PHD) értekezés, 2006 A „B” és „C” modellek készítése után megkértem a résztvevőket, írják le, mely ponton melyik elemzési mintát alkalmazták és miért; és hogy véleményük szerint hasznos-e az elemzési minták ismerete, segít-e a megoldás elkészítésében és miért! A fejezetben először ismertetem a feladatot, majd megadok két megoldást (1. és 2. verzió), mely véleményem szerint jól használja Fowler elemzési mintáit. Közben ismertetem a használt elemzési mintákat is. Ezután elemzem a beadott munkákat; ezek közül egyet bővebben is ismertetek. A felmérésben résztvevők véleményeinek közlése után összefoglalom az eredményeket.

11.1. A feladat – szakterületi modell készítése A megadott nagyvonalú feladatleírás alapján el kell készíteni egy szakterületi (elemzési) modellt. Nagyvonalú feladatleírás A cél egy olyan alkalmazás készítése, mely lehetővé teszi − az MLSZ (Magyar Lábtengó Szövetség) szervezeteinek, valamint a szervezetekkel munka- vagy tagsági kapcsolatban lévő személyek szükséges adatainak nyilvántartását; − a tagsággal rendelkezők számára igazolvány és a tagságot igazoló betétlap nyomtatását; − különböző kimutatások és jelentések készítését. A szakterületi fogalmak magyarázatát a Fogalomtár tartalmazza (lásd később). Az MLSZ aktuális szervezeti felépítését a 11.1. ábra mutatja, de a jövőben elképzelhetők szervezeti átalakítások. Az MLSZ szervezetei hierarchikus rendbe vannak szervezve. Minden szervezetnek van egy felügyeleti szervezete, legfelül az MLSZ központ áll. Egy felügyeleti szervezet egy vagy több felügyeleti szervezetet és/vagy tagszervezetet felügyel. A tagszervezetek a hierarchia végén találhatók, azok nem felügyelnek más szervezetet. A tagszervezetek és az MLSZ közötti szervezetek az ún. rétegszervezetek. Az ábra szerint az MLSZ központ alá tartozik több megyei központ; egy budapesti központ; és több olyan fővárosi kerületi szervezet, amely nem tartozik a budapesti központ alá. Az MLSZ közvetlen felügyelete alá tartozik továbbá több tagszervezet is. A kapcsolat végén szereplő csillag azt jelenti, hogy ott az adott típusú szervezetből akárhány szerepelhet.

112

11. Felmérés a mintahasználat hasznosságának bemutatására

MLSZ központ

* Megyei központ

Budapesti központ * Budapesti kerületi szervezet

* Tagszervezet

* Tagszervezet

* Fővárosi kerületi szervezet * Tagszervezet

* Tagszervezet

11.1. ábra. Az MLSZ szervezeti hierarchiájának sematikus rajza Az MLSZ szervezetei munka, illetve tagsági kapcsolatban állhatnak személyekkel. Minden felügyeleti szervezet munkakapcsolatban van egy elnökkel és egy főtitkárral, a tagszervezetek élén egy vezető áll. A tagszervezeteknek tagjai vannak. Egy személynek többféle munkakapcsolata lehet az MLSZ-szel, és tag lehet akárhány tagszervezetben függetlenül attól, hogy milyen munkakapcsolatai vannak. A program főbb tevékenységei a különböző nyilvántartások, valamint dokumentumok és jelentések készítése. Részletesebben: Nyilvántartások: − A felügyeleti szervezetek (MLSZ központ és a rétegszervezetek) nyilvántartása. Főbb jellemzők: a szervezet neve, címe, elérhetőségek, a megalakulás dátuma, a szervezeti hierarchiában elfoglalt helye (érvényesítő szervezete, illetve a felügyelete alá tartozó szervezetek), főtitkárának és elnökének adatai; − Tagszervezetek nyilvántartása. Főbb jellemzők: a tagszervezet neve, címe, elérhetőségek, a megalakulás dátuma, a tagszervezet felügyeleti szervezete, vezetőjének adatai; − Az MLSZ-szel munkakapcsolatban és/vagy tagsági kapcsolatban levő személyek nyilvántartása: név, cím, születési dátum és oklevelek: Kitüntetések (kitüntetés neve, dátuma), Minősítések (minősítés neve, dátuma), Képesítések (képesítés neve, típusa, 113

Angster Erzsébet: Doktori (PHD) értekezés, 2006 fokozata, szakága, dátuma és pecsétszáma). Nyilván kell tartani, hogy a személy melyik évben, melyik szervezetnek tagja, milyen kategóriában (ifjúsági, aktív, nyugdíjas). Egy személynek egy tagszervezetben egy évben csak egy tagsága lehet. Dokumentumok és jelentések készítése: − Igazolványok, betétlapok nyomtatása; − Egy felügyeleti szervezet jellemzői és felügyelt szervezetei, az alá tartozó tagszervezetek létszámadataival (tagsági kategória szerinti bontásban); − Felügyeleti szervezetek listája adott paraméterekkel; − Tagszervezetek listája adott paraméterekkel (pl. adott létszám alatti tagszervezetek); − Taglisták adott paraméterekkel (pl. adott tagszervezetnél adott évben érvényes tagsággal rendelkezők listája, kategóriák szerinti összesítés stb.); − Személyek listái. Egy személy milyen tagszervezetnél rendelkezik tagsággal, lett-e számára igazolvány és betétlap nyomtatva; vezetők listája stb. − Statisztikai adatok az igazolványokról és betétlapokról. Fogalomtár Betétlap

Felügyeleti szervezet (Érvényesítő szervezet) Igazolvány Közvetlen tagszervezet Munkakapcsolat (Tisztség) Rétegszervezet Személy Szervezet

114

Egy konkrét tagság adatait tartalmazó, az MLSZ által kiadott irat. A betétlapnak a személy MLSZ igazolványában van a helye. Egy személynek több érvényes betétlapja is lehet attól függően, hány tagszervezet tagja az adott évben. Egy szervezethez felülről kapcsolódó szervezet. Legfelül az MLSZ központ áll, annak nincs felügyeleti szervezete. A felügyeleti szervezetnek van egy elnöke és egy főtitkára. A felügyeleti szervezetnek közvetlenül nincsenek tagjai. Felügyeleti szervezet például a budapesti központ, valamint a budapesti kerületi szervezetek. Egy tagot igazoló, az MLSZ által kiadott irat. Az igazolványt az első tagsági betétlappal együtt kapja meg a tag. Olyan tagszervezet, melynek közvetlenül az MLSZ központ a felügyeleti szervezete. Személy kapcsolata egy szervezettel, mely alapján munkát végez. A munkakapcsolatnak van típusa, mint elnök, főtitkár stb. Felügyeleti (érvényesítő) szervezet, amely nem az MLSZ központ. Az MLSZ-szel munkakapcsolatban vagy tagsági kapcsolatban lévő ember. Munkakapcsolat lehet például: elnök, főtitkár vagy vezető. Van neve, címe, születési dátuma. Több emberből álló csoport, jogi személyiség.

11. Felmérés a mintahasználat hasznosságának bemutatására Oklevél

Tag Tagság

Tagsági kategória Tagszervezet

Az oklevél egy eredmény (itt az MLSZ-en belül elért) írásos bizonyítéka. Ilyen a kitüntetés, a minősítés, a túravezetői és a vizsgabiztosi képesítés. Kitüntetést, minősítést, képesítést csak érvényes tagsággal rendelkezők kaphatnak. A minősítés a szerzett pontok után jár, mely pontokat bármely szakágban megszerezheti a tag. Képesítést (túravezetői és vizsgabiztosi) egy adott szakágban lehet szerezni (pl. kerékpár, vízisí), három fokozata van (alap közép és felső), és a pecsétszám azonosít. Egy személy tag, ha van érvényes tagsága egy vagy több tagszervezetben. Egy személy kapcsolódása egy tagszervezethez egy adott évben. A tagságnak kategóriája van (lásd Tagsági kategória). Az MLSZ minden tagsághoz kiállít az igazolványhoz egy betétlapot. A tagság lehet érvényes vagy lejárt. A tagság jellemzője. Lehetséges értékei: ifjúsági, aktív vagy nyugdíjas. Egyesület, szakosztály, vagy oktatási, művelődési vagy egyéb intézményben működő csoport. Tagjai az adott évben az adott szervezetnél tagsággal rendelkező személyek. Van egy vezetője.

Először ismertetek két megoldást: a 11.2. ábra és 11.6. ábra a feladat szakterületi modelljének két verziója, melyeket én készítettem. A modelleket a kísérletben résztvevőkkel egy munkamegbeszélésen részletesen elemeztük, és a javasolt kisebb módosításokat elvégeztem. Természetesen egy megoldást többféleképpen lehet modellezni. Azonban a jó modellek közt is van használható és kevésbé használható Fowler [1997]. Fowler szerint a modellalkotáskor mérlegelni kell, hogy a megoldás mennyire legyen általános: a speciális (a feladatot jobban tükröző) modellel szemben egy általános modell általában egyszerűbb (kevesebb osztályt tartalmaz), az esetleges változtatásokat könnyebb átvezetni, viszont több megszorítást igényel. A modell készítésekor törekedni kell az újrahasználhatóságra, így az egyszerűségre és az érthetőségre. Az első verzióban (11.2. ábra) a szervezeteket specializálom: a Tagszervezet és a Felügyeleti szervezet a Szervezet osztály leszármazottja. A második verzióban (11.6. ábra) a szervezeteket egyetlen osztállyal modellezem.

11.2. Megoldás – 1. verzió Az első verziót a 11.2. ábra mutatja. Magyarázatok az egyes osztályokhoz: − Szereplő: A Személy és a Szervezet közös adatait (név, cím stb.) tartalmazó ősosztály. 115

Angster Erzsébet: Doktori (PHD) értekezés, 2006 − Személy: A Szereplő tulajdonságain kívül a Személynek van születési dátuma. Munkavállalóként akárhány munkakapcsolata lehet a szervezetekkel, és tagként akárhány tagsága lehet a különböző tagszervezetekben (megszorítás: egy személynek egy tagszervezetben egy évben csak egy tagsága lehet). A személynek lehet akárhány oklevele, és lehet igazolványa. − Szervezet: A Szereplő tulajdonságain kívül a Szervezetnek vannak elérhetőségei, megalakulási dátuma és munkakapcsolatai. Példány csak valamelyik leszármazottból hozható létre. − Tagszervezet: Szervezet, melyhez tagságok kapcsolódnak. Van egy felügyelő szervezete, melynek osztálya Felügyeleti szervezet. − Felügyeleti szervezet: Szervezet, melynek nulla vagy egy felügyeleti szervezete van, és akárhány tagszervezetet és más felügyeleti szervezetet felügyel. Megszorítás: a hierarchiában az MLSZ központ van legfelül, annak nincs felügyelője, minden más szervezetnek van. A hierarchiában nem lehet hurok! Szereplő Bizonyos munkakapcsolatok esetén a Szervezet típusa kötött: - Vezető: Tagszervezet - Főtitkár: Felügyeleti szervezet - Elnök: Felügyeleti szervezet

-

név: cím:

Munkakapcsolat típus -

név: *

-

+munkavállaló

szül_dátum:

*

-

Igazolvány

kiállítás_dátum:

név:

-

*

+munkaadó -

* Tagság

igazolvány_szám: kiállítási_dátum:

Minősítés -

időtartam:

telefonszámok: fax: email: alakulás_dátuma:

0..1

* Oklevél

Kitüntetés

-

+tag

*

-

Szervezet

Munkakapcsolat

Személy

név: pontszám:

-

típus: fokozat: szakág: pecsétszám:

+felügyelt *

Betétlap

Képesítés -

év: kategória:

-

Felügyelet

Tagszervezet

kiállítási_dátum:

*

Egy személynek egy tagszervezetben egy évben csak egy tagsága lehet.

+felügyelő Felügyeleti 0..1 szervezet Felügyelet

+felügyelő

Az MLSZ központ van legfelül, annak nincs felügyelője. A hierarchiában nem lehet hurok!

11.2. ábra. A feladat szakterületi modellje – 1. verzió 116

+felügyelt *

11. Felmérés a mintahasználat hasznosságának bemutatására − Munkakapcsolat: A rendszerben a személyek munkakapcsolatban állhatnak a szervezetekkel. A Munkakapcsolat egy példánya egy konkrét Szervezetet és Személyt köt össze: a szervezet a munkaadó, a személy pedig a munkavállaló. Például a Budapesti központ főtitkára Lovas Lehel. − Munkakapcsolat típus: Minden munkakapcsolatnak (tisztségnek) van egy típusa, amit a neve jellemez, például vezető, főtitkár vagy elnök. Bizonyos munkakapcsolat típusok munkakapcsolataihoz konkrét szervezet típushoz vannak kötve, például vezetője csak tagszervezetnek, főtitkára és elnöke csak felügyeleti szervezetnek lehet. − Oklevél: Bármely személynek lehet akárhány oklevele, és egy oklevélnek több tulajdonosa is lehet. Az oklevélnek van egy kiállítási dátuma. − Kitüntetés: Speciális oklevél, melynek van neve. − Minősítés: Speciális oklevél, melynek van neve és pontszáma (a minősítést az elért pontszám alapján adják). − Képesítés: Speciális oklevél, melynek van típusa (pl. játékvezető, vizsgabiztos), fokozata (alap, közép és felső), szakága és pecsétszáma. − Igazolvány: Az MLSZ-szel valamikor tagsági viszonyban álló személynek van igazolványa. Az igazolványnak van száma és kiállítási dátuma. − Tagság: Egy tagság egy tagszervezet és egy személy közötti kapcsolat. Van éve (a tagság egy adott évre szól), és van kategóriája (ifjúsági, aktív, nyugdíjas). − Betétlap: Az igazolvány betétlapja a tagságot igazolja. A betétlap egy konkrét tagsághoz, azon keresztül egy konkrét Tagszervezethez és Személyhez tartozik. Van kiállítási dátuma. 11.3. Felhasznált minták Fowler elemzési mintáiból Szereplő A Szereplő minta (lásd 11.3. ábra) lényege, hogy a Személynek és a Szervezetnek van egy közös őse, a Szereplő. A Szereplő osztály sok közös tulajdonságot és kapcsolatot tartalmaz.

117

Angster Erzsébet: Doktori (PHD) értekezés, 2006 Szereplő

Személy

Szervezet

11.3. ábra. Szereplő elemzési minta A Szereplő minta megvalósítása az MLSZ rendszerben a Szereplő osztály és leszármazottai (lásd 11.2. ábra). Szervezeti hierarchiák A Szervezeti hierarchiák minta (lásd 11.4. ábra) egy általános, rugalmas modellt kínál tetszőleges, hierarchikus rendbe szervezett szervezetek modellezésére. A szervezeteknek van egy közös ősosztálya (a Szervezet), amely megvalósítja a kapcsolatokat. A szervezetenkénti egyedi jellemzők a megfelelő származtatott osztályokban vannak. A modellben könnyedén felvehetők újabb szervezetek. Mivel a modell elvileg megenged bármilyen alá- és fölérendeltséget, megszorításokban kell megadnunk a szabályokat. A minta alkalmas több, egymástól független hierarchia modellezésére: ilyenkor ugyannak a szervezetnek több szülője is lehet, igaz, mindegyik más hierarchia, más szempont szerint. Kettőnél több hierarchia esetén a modell könnyen áttekinthetetlenné válik – erre az esetre való a Szervezeti struktúra elemzési minta. Szervezet

hierarchia1 * hierarchia2 *

SpecSzervezet1

SpecSzervezet2

11.4. ábra. Szervezeti hierarchiák elemzési minta 118

11. Felmérés a mintahasználat hasznosságának bemutatására A Szervezeti hierarchiák minta megvalósítása az MLSZ rendszerben a felügyeleti szervezetek közötti Felügyelet kapcsolat (lásd 11.2. ábra). Mivel ebben a rendszerben mindössze egyetlen hierarchia van, a Szervezeti hierarchiák minta jól használható. Kevésbé lenne áttekinthető a modell, ha a szervezetek közötti „Felügyelet” kapcsolatot (felelősséget) összevonnánk a Szervezet és Személy közötti kapcsolatokkal (felelősségekkel). Felelősség A Felelősség minta (11.5. ábra) egy általános megoldást kínál tetszőleges szereplők közötti felelősségek (kapcsolatok) modellezésére (például két szervezet között egy felügyeleti viszony, két személy között egy megállapodás, vagy egy szervezet és egy személy között egy munkaviszony vagy tagság.) A felelősségi kapcsolat két tetszőleges szereplő között van: az egyik a fölérendelt, a másik az alárendelt. A felelősségek típusokba sorolhatók. A Felelősség minta bevezetésével a modellezhető esetek száma sokszorosára nő anélkül, hogy a modell bonyolultabbá válna. Felelősségtípus

Szereplő

*

+megbízott (fölérendelt) +felelős (alárendelt)

Felelősség * *

Személy

Szervezet

*

Időtartam

11.5. ábra. Felelősség elemzési minta

Az MLSZ-ben a Felelősség mintát megszorítással használom (lásd 11.2. ábra); a felelősség csak Szervezet és Személy között jöhet létre. A modellen ilyen felelősség a Munkakapcsolat és a Tagság. Az MLSZ modellben háromféle „felelősség” van: Felügyelet (két felügyeleti szervezet között, illetve egy felügyeleti szervezet és egy tagszervezet között), Munkakapcsolat

119

Angster Erzsébet: Doktori (PHD) értekezés, 2006 és Tagság (Személy és Szervezet között). Ezeket a felelősségeket össze lehetne vonni egyetlen Felelősség minta alkalmazásával. Én a háromféle felelősséget külön kezelem, mert így (1) a modell érthetőbb; (2) sokkal kevesebb megszorítást kell megadni; (3) a szétválasztás az újrahasználást nem veszélyezteti.

11.4. Megoldás – 2. verzió A második verziót a 11.6. ábra mutatja. Itt a szervezeteket egy osztályban modellezem. A Szervezet osztályban most kell egy típus jellemző, amely megmondja, hogy az adott objektum milyen típusú szervezet. Most az osztályok száma kettővel kevesebb, ezért a továbbfejlesztés szempontjából rugalmasabb, viszont több a megszorítás: ki kell kötni például, hogy a Tagság csak Tagszervezettel állhat kapcsolatban, hiszen a modell alapértelmezésben bármely Szervezetet megenged. A Szervezeti hierarchiák minta most „felszállt” a Szervezet osztályra. Szereplő Bizonyos munkakapcsolatok esetén a Szervezet típusa kötött: - Vezető: Tagszervezet - Főtitkár: Felügyeleti szervezet - Elnök: Felügyeleti szervezet

-

Típus: Felügyeleti szervezet, Tagszervezet

név: cím:

Az MLSZ központ van legfelül, annak nincs felügyelője. Egy Szervezet felügyelője csak Felügyeleti szervezet lehet. A fában nem lehet hurok!

Munkakapcsolat típus -

név: * Szervezet Munkakapcsolat

Személy -

+munkavállaló

szül_dátum:

+tag

*

-

időtartam:

*

*

Oklevél -

Tagság

0..1

*

Igazolvány

kiállítás_dátum:

-

*

igazolvány_szám: kiállítási_dátum:

-

év: kategória:

+munkaadó -

típus: telefonszámok: fax: email: alakulás_dátuma:

Kitüntetés -

név:

Minősítés -

-

kiállítási_dátum:

típus: fokozat: szakág: pecsétszám:

11.6. ábra. A feladat szakterületi modellje – 2. verzió

120

+felügyelt *

Tagság csak Tagszervezettel jöhet létre. Egy személynek egy tagszervezetben egy évben csak egy tagsága lehet.

Képesítés

név: pontszám:

Felügyelet

*

Betétlap -

+felügyelő 0..1

11. Felmérés a mintahasználat hasznosságának bemutatására 11.5. A beadott munkák elemzése Mindkét csoportban három oktató, egy fejlesztő és egy hallgató vett részt. Az első csoportból az „A” modellt mindenki beadta, a „B” modellt egy oktató kivételével mindenki beadta. A második csoportból mindenki megadta a „C” modellt. A 10 résztvevőből 8 írt véleményt. 1. csoport Minta

„A” modell: az elemzési minták tanulmányozása előtt Okt1 Okt2 Okt3 Fejl1 Hallg1

„B” modell: az elemzési minták tanulmányozása után Okt1 Okt2 Okt3 Fejl1 Hallg1

Szereplő

–

–

–

5

–

5

–

N

5

5

Szervezeti hierarchia

4

5

–

5

3

4

5

N

5

4

Felelősség

–

–

–

–

–

2

–

N

5

4

A modell osztályzata

3

4

2

3

3

2

4

N

5

4

2. csoport Minta

„C” modell: az elemzési minták tanulmányozása után Okt4 Okt5 Okt6 Fejl2 Hallg2

Szereplő

5

5

–

5

2

Szervezeti hierarchia

4

–

5

5

4

Felelősség

5

4

3

3

3

A modell osztályzata

5

4

3

4

3

11.7. ábra. A beadott munkák értékelése

Ahogy várható volt, a beadott modellekben elsősorban a következő minták fordultak elő: Szereplő, Szervezeti hierarchia és Felelősség (mindössze egy ember használta a Szervezeti struktúra mintát, egy másik pedig az Ismereti szintű felelősség mintát, de helytelenül). A 11.7. ábra mutatja, hogy a beadott modelleken a részvevők használják-e az adott elemzési mintát és hogy mennyire használják helyesen, valamint hogy a beadott modell összességében mennyire jó. A táblázat jelölései: − A minta osztályzata (1 és 5 között, N: nem adta be, –: nem használta a mintát). 1-est kapott a minta, ha az illető nagyon helytelenül használta; 3-mast ha közepesen helytelenül használta; és 5-öst, ha helyesen használta. 121

Angster Erzsébet: Doktori (PHD) értekezés, 2006 − A modell osztályzata (1 és 5 között, N: nem adta be): 5-öst kapott az a modell, amely az adott feladat megoldását modellezi, a szabványos jelöléseket helyesen alkalmazza, és a modellben nincsenek logikai és durva rugalmatlansági hibák. A jelen kísérlet folyamán beadott modellek mindegyikében van több-kevesebb hiba. A táblázat csak tájékoztató jellegű, mivel egyrészt a beadott munkák száma kevés, másrészt a helyességet és a jóságot nem lehet egyértelműen mérni. Mivel a beadott munkák egyenkénti részletes elemzése rendkívül terjedelmes lenne, csak egy áttekintést adok a jellemző megoldásokról, hibákról és az alkalmazott mintákról, majd ismertetem az egyik beadott megoldást. A táblázatból kiolvasható, hogy a „B” és „C” modelleken (a táblázat szürkén jelölt részén), az elemzési minták tanulmányozása után, a minták alkalmazása gyakoribb és helyesebb. Az eredményt, konklúziót lásd a 11.8. pontban. A következőkben ismertetem a tipikus hibákat, majd röviden elemzem a résztvevők munkáit. Az „A” és „B” modellekben egyaránt vannak hibák az elemzési minták használatától függetlenül. Logikai hibák: − A feladat helytelen értelmezése: Volt aki a modellben kizárta a többszörös tagságot, vagy egy személyt automatikusan tagnak vett. − Örökítés helytelen alkalmazása. Többen a Személy osztályból származtatnak olyan osztályokat, mint Irányító vagy Tag, ami helytelen, mert az egyes osztályokból létrehozott példányok halmaza nem diszjunkt (a személy lehet tag is, irányító is, egymástól függetlenül). − Objektum és osztály keverése: Sokan az MLSZ központot osztálynak vették, pedig az egy objektum: az Érvényesítő szervezet egy példánya, mely a hierarchia tetején áll. − Megszorítások hiánya: A modell általánosításával párhuzamosan a résztvevők nem adtak meg megszorításokat, mint például „Munkakapcsolat csak Szervezeti egység és a Személy között lehet.” vagy „A Tagság csak a Tagszervezet és a Személy között lehet.” Rugalmatlansági hibák: − Feleslegesen sok Szervezet osztály: Több modellben a Szervezet osztály leszármazottai az Érvényesítő szervezet és a Tagszervezet, majd az Érvényesítő szervezet osztály további leszármazottai az MLSZ központ és a Rétegszervezet. Nincs értelme új osztályt 122

11. Felmérés a mintahasználat hasznosságának bemutatására létrehozni, ha abban nincs plusz tulajdonság, kapcsolat vagy megszorítás. A feladat elemzése során kiderül, hogy az érvényesítő szervezet megegyezik a rétegszervezettel, és mindkettő felügyeleti szervezet. Az MLSZ központ egy olyan felügyeleti szervezet, amelynek nincs felügyeleti szervezete. − Adatok párhuzamos felvétele: A Személy és a Szervezet több közös adatot tartalmaz (ráadásul a cím összetett adat). Ez redundancia. − Munkakapcsolatok „beégetése” modellbe: Ha új munkakapcsolatot is kezelni kell a rendszerben (nem csak az elnököt, főtitkárt és vezetőt, hanem például adminisztrátort is), akkor a modellt teljesen át kell szerkeszteni. Az egyes modellek elemzése: 1. csoport (beadták az „A” és „B” modellt is): − Oktató1: Az ő második modellje rosszabb, mint az első. Határozottan látszik, hogy a minták megzavarták. A mintákat ugyan megértette, de nem tudta helyesen alkalmazni őket. A modellt nagyon elbonyolította, és az eredeti hibák is benne maradtak. Az Ismereti szintű felelősség mintát helytelenül alkalmazza. − Oktató2: Az ő „A” modellje az átlagosnál jobban sikerült, lényegében alkalmazta a Szervezeti hierarchiák és a Felelősség mintákat. Sajnos azonban „B” modellként ugyanezt a modellt adta be, mert – mint írta, – ennél jobbat az elemzési minták ismeretében sem tud készíteni. Pedig a modellt lehetett volna javítani. A Szereplő minta alkalmazásának hiányában a modellben redundanciák vannak. A Munkakapcsolat és a Tagság felelősségeket alapvetően jól modellezte, de a Felelősség-típus lemaradt. A modellről hiányoznak osztályok és megszorítások. − Oktató3: Az „A” modell meglehetősen gyengére sikerült, sok benne a logikai és a rugalmassági hiba. Például négy Szervezet osztály van, melyeknek nincs is közös ősük; és a munkakapcsolatok be vannak égetve a modellbe. Az oktató sajnos – idő hiányában – nem adott be „B” modellt. − Fejlesztő1: Az „A” modellben helyesen alkalmazta a Szereplő és a Szervezeti hierarchiák mintákat, de a Felelősség minta ismeretének hiányában a konkrét munkakapcsolatok be vannak égetve a modellbe. Kisebb logikai hibák is vannak a modellen. A „B” modell szinte tökéletes.

123

Angster Erzsébet: Doktori (PHD) értekezés, 2006 − Hallgató1: A hallgató „A” modellje közepesre sikerült. Csak a Szervezeti hierarchiák mintát alkalmazta, de azt sem helyesen. A „B” modellen megjelenik mindhárom minta, bár a Felelősség minta alkalmazásába kisebb hiba csúszott (lásd 11.6. pont). 2. csoport (csak a „C” modellt adták be): − Oktató4: Mindhárom mintát (Szereplő, Szervezeti hierarchia és Felelősség) helyesen alkalmazza, csak a Szervezeti hierarchiában nem ad meg megszorításokat. − Oktató5: A Szereplő mintát helyesen alkalmazza. A Szervezeti hierarchiát és más felelősségeket egyetlen Felelősség osztályban valósítja meg, de a Szereplő és a Felelősség osztály között csak az egyik kapcsolatot jelöli. Feleslegesen sok Szervezet leszármazottat ad meg. − Oktató6: A Szereplő mintát nem használja, mert szerinte így érthetőbb a modell. A Szervezeti hierarchiát leválasztja a felelősségekről, és helyesen alkalmazza. A felelősségeket túl sok osztályba sorolja, elvesztve ezzel az általánosságot. − Fejlesztő2: A Szereplő és a Szervezeti hierarchia mintákat helyesen alkalmazza, a megszorításokat megadja. A munkakapcsolatokat és a tagságot egyetlen felelősség osztályba olvasztja, de nem vesz fel hozzá felelősség-típus osztályt. − Hallgató2: A modell közepesen jó. A Szereplő mintát tévesen alkalmazza, abból származtatja a tagot. A szervezeti felügyeletet a Szervezeti struktúra mintával oldja meg, de a magyarázatban kiderül, hogy helyesebb lett volna a Szervezeti hierarchiák mintát alkalmazni. A Felelősség mintát a munkaköri felelősségekre és a tagságra egyben alkalmazza, de hibásan. 11.6. Egy konkrét beadott munka Kiválasztottam az első csoport hallgatóját (Hallgató1), akinek a modelljein jól lehet érzékeltetni az elemzési minták használhatóságát. A hallgatónak az elemzési minták tanulmányozása előtti, „A” modelljét a 11.8. ábra mutatja. A hallgatónak a feladat nagy részét sikerült jól lemodelleznie, de a megoldás csak közepesen jó: a modellben vannak logikai és rugalmatlansági hibák. Logikai hibák:

124

11. Felmérés a mintahasználat hasznosságának bemutatására − Az MLSZ központ is szervezet, vagyis a Szervezet osztály utódja (a központnak is van neve, címe stb.). Az elnevezése is helytelen, mert az MLSZ központ nem osztály, hanem objektum. − Az MLSZ-nek is lehet tagszervezete, nem csak a Rétegszervezetnek. − A Szervezet absztrakt, hiszen minden szervezet vagy központ, vagy a Rétegszervezet vagy Tagszervezet. − A Szervezet osztályban nem kell az érvényesítő_szerv adat, hiszen ez egy rétegszervezetre mutató referencia, amit az UML kapcsolat már ábrázol. − Hiányoznak a modellről olyan osztályok, mint Igazolvány, Betétlap.

Szervezet -

név: cím: email: telefonszám: fax: érvényesítő_szerv:

Rétegszervezet

0..1

MLSZ központ *

*

Tagszervezet

* 0..1

+főtitkár Oklevél -

név: dátum:

Képesítés

Kitüntetés -

-

*

0..1

0..1

*

+elnök Személy

+vezető

név: cím: email: szül_dátum:

+tag *

Tagság -

kategória: dátum:

Minősítés

fokozat: szakág:

11.8. ábra. Hallgató1 „A” modellje

125

Angster Erzsébet: Doktori (PHD) értekezés, 2006 Rugalmatlansági hibák (a feladat esetleges változásait nehéz átvezetni a modellen): − Felesleges szétválasztani a rétegszervezeteket és az MLSZ központot. Mindkettő felügyeleti szerv. − A Személy és a Szervezet több közös adatot tartalmaz. Ez redundancia. − A munkakapcsolatok (elnök, főtitkár és vezető) bele vannak „égetve” a modellbe. A hallgatónak az elemzési minták tanulmányozása utáni, „B” modelljét a 11.9. ábra mutatja. A Felelősség minta bevezetésével a modell most rugalmasabbá vált, mert a munkakapcsolatok nincsenek beégetve a modellbe. Viszont most újabb logikai és rugalmatlansági hibák kerültek a modellbe. Tagság

-

Szereplő

+fölérendelt

név: cím: email:

+alárendelt

Személy -

Munkakapcsolat

Felelősség

-

telefonszám: fax: évvényesítő_szerv:

* Oklevél -

Kitüntetés

Felügyeleti szervezet

név: dátum:

Képesítés -

Tagszervezet

Minősítés

fokozat: szakág:

11.9. ábra. Hallgató1 „B” modellje

126

Időtartam *

Szervezet

szül_dátum:

Felügyelet

11. Felmérés a mintahasználat hasznosságának bemutatására Logikai hibák: − Mivel az összes felelősség, így a szervezeti hierarchiák is „felvándoroltak” a felelősségek közé, a hierarchikus kapcsolatokról szóló megszorításokat most itt kell elhelyezni, mint: „Tagság csak Tagszervezet és Személy között lehet”, vagy „Érvényesítésben a Tagszervezet nem lehet fölérendelt”. Sajnos sok megszorítás kell, melyek hiányoznak a modellről. − A Szervezetben itt sem kell az érvényesítő_szerv adat. A felelősség objektum köti össze a szereplőket, ő hordozza a referenciákat. De ott se kell feltüntetni, mert a kapcsolat vonala hordozza ezt az információt. − A modellen most a Felelősség osztály leszármazottai a Tagság, a Munkakapcsolat és Felügyelet. De munkakapcsolat többféle lehet, ezért meg kellett volna adni annak típusát. Rugalmatlansági hibák (a feladat esetleges változását nehéz átvezetni a modellen): − A modell most áttekinthetetlenebb, mert az összes felelősség egy osztályba van olvasztva. A Felelősség specializálásával javul a helyzet, mert ezzel szétválaszthatjuk a a megszorításokat. Áttekinthetőbb lenne azonban a modell, ha a háromféle felelősséggel összekapcsolnánk a megfelelő osztályokat (lásd 11.6. ábra felelősségei). − Feleslegessé vált a Tagszervezet és a Felügyeleti szervezet. Az „A” modellen megkülönböztettünk kapcsolatokat (például a tagság vagy a vezető), amire most már nincs szükség az általános Felelősség minta bevezetésével. A szervezet típusa most a Szervezet osztály egy tulajdonsága kell legyen. A hallgató koncepciójának helyes kivitelezését a 11.10. ábra mutatja.

Összesítés: A hallgató az elemzési minták ismeretében sokat javított az „A” modelljén. A Szereplő minta felismerésével és alkalmazásával feloldott egy redundanciát, de ami sokkal fontosabb, a Felelősség minta alkalmazásával kijavította a munkakapcsolatok beégetésével okozott durva rugalmassági hibát. Sajnos azonban nem vette észre az általános és speciális lehetőségek között az „arany középutat”.

127

Angster Erzsébet: Doktori (PHD) értekezés, 2006 Munkakapcsolat típus Szervezet és Személy között.

-

A típus lehet elnök, főtitkár stb.

név:

Felügyeleti szervezet és Szervezet között.

* Tagság

Munkakapcsolat

Felügyelet

Tagszervezet és Személy között.

-

Szereplő

+fölérendelt

név: cím: email:

+alárendelt

szül_dátum:

Időtartam *

Szervezet

Személy -

Felelősség

-

típus: telefonszám: fax:

* Oklevél -

név: dátum:

Kitüntetés

Képesítés -

Minősítés

fokozat: szakág:

11.10. ábra. Hallgató1 „B” modelljének javított változata

11.7. Vélemények A kísérletben résztvevők véleménye szerint a minták hasznosak, sokat segítenek a modellalkotásban. Volt, aki szerint a minták nem elég absztraktak, többen pedig a konkrét példát, implementációt hiányolták. Volt, aki úgy gondolja, hogy bár a mintaismeret sokat segít a szakterületi modell moduláris megközelítésében, vigyázni kell, nehogy a minták ismerete a “feladatot igazítom a modellekhez” helyzethez vezessen. A konkrét vélemények: „A minták ismerete, illetve használata mindenképpen hasznos, hiszen egy már végiggondolt problémára ad egy sablonmegoldást, amit konkrét feladatokban hasznosítani lehet. Olyan eseteket is tárgyalhat egy modell, amire az ember [vagy egyáltalán] nem is gondolna, vagy 128

11. Felmérés a mintahasználat hasznosságának bemutatására csak a tervezés egy későbbi fázisában. Ezek eredményeképpen a fejlesztési idő jelentősen lecsökkenhet.” „Nekem [az elemzési minták] nehezek voltak, eddig azzal sem voltam igazán tisztában, mi is az a szakterületi modell. De nekem megérte ez az egész, mert most már látom, mennyire fontos a szakterületi modell. Tágult a látóköröm, javult a modell-alkotó képességem.” „Sokat kínlódtam a modell elkészítésével. Fowler mintái segítettek, de azt hiszem, nem sikerült teljesen a végére járnom. Biztosan lehetne jobbat csinálni.” „Általánosságban az olvasott mintákról annyi megjegyezni valóm van, hogy bár ezek a kitűzött feladathoz kiválóan illeszkedtek és a kitűzött feladat egy elég jellemző problémát testesít meg, de egy mintától én még magasabb absztrakciót várnék el. [A tananyagban] szerintem csak kiváló esettanulmányokat láthatunk a mintákhoz.” „Jó lenne, ha az elemzési mintákhoz konkrét és teljes modelleket is láthatnánk. Például amilyent most csinálunk.” „Tapasztalataim a mintaismerettel kapcsolatban: (1) A Szereplő, Szervezeti struktúra és Felelősség minták ismerete zavaró a tapasztalati szervezeti modell felállításában, vagyis akkor, amikor követelménygyűjtési, üzleti modellezési szakaszban vagyunk. Erősen kell koncentrálni arra, hogy ne vegyem a mintákat figyelembe. (2) Az elemzési munkafolyamat során nagyon kell vigyázni, hogy a minták ismerete ne vezessen a “feladatot igazítom a modellekhez” helyzethez. Ha ezt sikerül elkerülni, a mintaismeret sokat segít a szakterületi modell moduláris megközelítésében. (3) A valódi minta-valóság kapcsolatok felismerése és alkalmazása után – ha van az egész feladatot lefedő minta – az könnyen felismerhető, sőt olyan megoldásokat is biztosíthat, amire korábban nem gondoltunk. Itt ilyen például a személyek (hivatali) hierarchiájának kezelési lehetősége, amelyet a minta biztosít.” „Véleményem szerint az elemzési minták megértése nem olyan egyszerű, de nagyon hasznos. A kapott tananyag sokat segített a minták megértésében. Jó lenne, ha minden minta ilyen érthetően le lenne írva! A mintákat nehezen és lassan, de megértettem, és alkalmazásuk nagy örömöt és szellemi élményt jelentett nekem. A megoldás során szerzett tapasztalatok meggyőztek arról, hogy megéri megismerni a mintákat, és hogy minden komoly tervezőnek ismerni kell a fontosabb mintákat.”

129

Angster Erzsébet: Doktori (PHD) értekezés, 2006 11.8. Eredmény, konklúzió A vizsgálat alacsony száma miatt az egyes modellcsoportok összehasonlítása nem megbízható. Látható azonban, hogy a felmérésben a „B” és „C” modellek jobbak, és ezekben többen használnak mintát (11.11. ábra).

Minta Szereplő

„A” modell Hányan Helyesség használták 1 5

„B” modell Hányan Helyesség használták 3 5

„C” modell Hányan Helyesség használták 4 4.25

Szervezeti hierarchia

4

4.25

4

4.5

4

4.5

Felelősség

0

0

3

3.66

5

3.6

A modell osztályzata

3

3.75

3.8

11.11. ábra. A modellek összehasonlítása Az „A” modellben a Szereplő mintát mindössze egy ember használta, a Szervezeti hierarchiák mintát négyen, a Felelősség mintát pedig senki. A „B” modellben a használatok száma már (3, 4, 3) a „C” modellben pedig (4, 4, 5). A legnagyobb „látszatja” a Felelősség mintának volt: az „A” modellben senki nem használta, a „B” modellben is csak egy nem használta, mivel egy résztvevő nem adta be a munkát. Az „A” modellben egy kivétellel nem is oldották meg rugalmasan a munkakapcsolatokat: mindenki valamilyen módon beégette – jól vagy rosszul – az elnök, a főtitkár és a vezető munkakapcsolatot. A táblázatból kiolvasható, hogy a részvevők a minták ismeretében igyekeztek minél több mintát alkalmazni, és hogy a „B” és „C” modellek jobbak, mint az „A”.

11.9. A mintahasználat hasznossága (7. tézis) A beadott megoldások és vélemények elemzése során kiderült: −

Modellezni nehéz; a beadott megoldásokban sok a logikai és rugalmatlansági hiba.

−

Az elemzési minták hasznosak, sokat segítenek a modellalkotásban, de

−

Az elemzési minták nem adnak teljes megoldásokat, csak ötleteket, alkalmazható sablonokat. A minták helyes alkalmazásához nagyfokú kreativitásra van szükség!

130

12. Hivatkozásjegyzék

12. Hivatkozásjegyzék [Abakusz, 2004]

Abakusz Szoftverfejlesztő és tehetségkutató verseny: http://gdf.hu/abakusz

[Agarwal, 1997]

R. Agarwal, J. Prasad: The Role of Innovation Characteristics and Perceived Voluntariness in the Acceptance of Information Technologies. Decision Sciences. 28(3), 557-582.

[AGCS, 2003]

AG Communications Systems. Patterns honlap. http://www.agcs.com/supportv2/techpapers/patterns. Accesses at 10th November, 2003.

[Alexander et al., 1977] Christopher Alexander, S. Ishicawa, M. Silverstein: A Pattern Language – Towns-Buildings-Construction. New York: Oxford University Press, 1977 [Alexander, 1979]

Christopher Alexander: The Timeless Way of Building. New York: Oxford University Press, 1979

[Alexander, 1996]

Christopher Alexander: Keynote address, OOPSLA Conference, San Jose, 1996

[Angster, 1997]

Erzsébet Angster: Simple and Complete Patterns Step by Step. Pedagogical Pattern #47. Protopattern, In: [PPP, 1996]

[Angster et al., 2004a]

Erzsébet Angster, Joe Bergin, Marianna Sipos: Patterns in Teaching Software Development. ECOOP 2003 Workshop Reader, Springer Verlag, 2004. LNCS 3013, ISBN: 3-540-22405-X, pp 130-142. http://springerlink.com

[Angster, 2004b]

Angster Erzsébet: Miért nincsenek mintaszerű szoftverfejlesztési csomagok? Informatika, 7. évf. 1. szám pp 56-62. 2004. február

[Angster, 2004c]

Erzsébet Angster: SDP-City against a Vicious Circle! First Monday, 2004, Volume 9, December, at http://firstmonday.org

[Angster, 2005a]

Erzsébet Angster: Professional Analysis of the "Abakusz" Software Development Competition. Proceedings of ISSEP 2005, Innovative Concepts for Teaching Informatics. Überreuter.

[Angster, 2005b]

Angster Erzsébet: Felelősség elemzési minták. Elektronikus tananyag , 2005. http://www.gdf.hu/progtanszek/ook

[Anthony, 1996]

Dana L. G. Anthony: Patterns for Classroom Education. In: (Vlissides et al., 1996)

[Attewell, 1992]

P. Attewell: Technology diffusion and organizational learning: The case of business computing. Organization Science. 3(1), 1-19.

[Baronas et al., 1988]

A. Baronas, M. Louis, M: Restoring a Sense of Control During Implementation: How User Involvement Leads to System Acceptance. MIS Quarterly, 12(1), 111-124.

131

Angster Erzsébet: Doktori (PHD) értekezés, 2006 [Beck et al., 1987]

Kent Beck, Ward Cunningham: Using Pattern Languages for ObjectOriented Programs. OOPSLA-87 workshop on the Specification and Design for Object-Oriented Programming.

[Bergin, 2003]

Joseph Bergin: E-mail levelezés, 2003

[Booch, 1994]

Grady Booch: Object-Oriented Analysis and Design with Applications. The Benjamin/Cummings Publishing Company, Inc.

[Brown et al., 1995]

Kyle Brown, Bruce Whitenack: Crossing Chasms – A Pattern Language for Object – RDBMS Integration. Paper. Knowledge Systems Corp. 1995. http://members.aol.com/kgb1001001/Chasms.htm, accessed at 5th December, 2002.

[Buschmann et al., 1996] Frank Buschmann – Regine Meunier – Hans Rohnert – Peter Sommerlad – Michael Stal: Pattern-Oriented Software Architecture. A System of Patterns. Chichester: John Wiley & Sons. [Chau, 1996]

P. Chau: An Empirical Investigation of Factors Affecting the Acceptance of CASE by System Developers. Information and Management, 30(6), 1996, pp269-280

[Coad et al., 1991]

Peter Coad, E. Yourdon: Object-Oriented Design. Englewood Cliffs, New Jersey, Yourdon Press, 1991

[Coad, 1992]

Peter Coad: Object-Oriented Patterns. CACM 35, 9 (September). p 152-159.

[Coplien et al., 1995]

James O. Coplien, D. C. Schmidt: Pattern Languages of Program Design. Reading. Addison-Wesley, 1995

[Coplien, 1992]

James O. Coplien: Advanced C++ Programming Styles and Idioms. Reading. MA: Addison-Wesley.

[Coplien, 1996]

James O. Coplien: Software Patterns. White paper. SIGS Books. http://www.belllabs.com/user/cope/Patterns/WhitePaper/SoftwarePatterns.pdf

[Coplien, 1998]

James O. Coplien: Object Magazine Online, January, 1998. In: Online Interview with James Coplien http://www.belllabs.com/user/cope/ObjectMagOnLineCoplienInterview.html

[Coplien, 2003]

James O. Coplien: The Pattern Definition (Software Patterns) http://hillside.net/patterns/definition.html, accessed at 10th november, 2003.

[Cunningham, 1994]

Ward Cunningham: The CHECKS. Pattern Language of Information Integrity. 1994. http://c2.com/ppr/checks.html

[Fafchamps, 1994]

D. Fafchamps: Organizational factors and Reuse. IEEE software (September). pp 31-44.

[Fayad et al., 1996]

Mohamed E. Fayad, Wei-Tek Tsai, Milton L. Fulghum: Transition to Object-Oriented Software Development, Communications of the ACM. 39(2), 109-121.

[Fichman et al., 1994]

Robert G. Fichman, Chris F. Kemerer: Toward a Theory of the Adoption and Diffusion of Software Process Innovations: Diffusion, Transfer and Implementation of Information Technology. IFIP TC8 Working Group Conference Proceedings. Champion, PA. L. Levine. New York, Elsevier Science Publications. pp 25-31.

[Fichman et al., 1997]

Robert G. Fichman, Chris F. Kemerer: The assimilation of Software Process Innovations: An Organizational Learning Perspective. Management Science, 1997, Volume 43, Issue 10, pp 1345-1363

132

12. Hivatkozásjegyzék [Fowler, 1997]

Martin Fowler: Analysis Patterns: Reusable Object Models, Addison Wesley, 1997

[Fowler, 1999]

Martin Fowler (1999): UML Distilled. Addison-Wesley

[Fowler, 2001]

Fowler, Martin (2001): Is Design Dead? http://www.martinfowler.com/articles/designDead.html

[Fowler, 2003a]

Fowler, Martin: Patterns of Enterprise Application Architecture. Reading. Addison-Wesley, 2003

[Fowler, 2003b]

Martin Fowler: The New Methodology. 2003. http://martinfowler.com/articles.html

[Fowler, 2003c]

Martin Fowler: Patterns. IEEE Software. 2003. March/April, 2-3.

[Fowler, 2003d]

Martin Fowler: Analysis Patterns 2 - Work in Progress. http://www.martinfowler.com, accessed at 15th December, 2003.

[FowlerP et al., 1993]

Priscilla Fowler, Linda Levine. A Conceptual Framework for Software Technology Transition, Part 1. (CMU/SEI-93-TR-031, ESC-TR-93-317). Software Engineering Institute, Carnegie Mellon University.

[FowlerP et al., 1995]

Priscilla Fowler, Linda Levine: Technology Transition Pull: A Case Study of Rate Monotonic Analysis, Part 2. (CMU/SEI-93-TR-030, ESC-TR-93204). Software Engineering Institute, Carnegie Mellon University. [Fowler, 1997]: Martin Fowler. Analysis Patterns: Reusable Object Models, Addison Wesley Longman, Inc., 1997. ISBN 0-201-89542-0

[Frakes et al, 1995]

W. B. Frakes, C. J. Fox: Sixteen Questions About Software Reuse. Communications of the ACM. 38 (6). 1995

[Gamma et al., 1993]

Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides: Design Patterns – Abstraction and Reuse of Object-Oriented Design. In: Proceedings of ECOOP '93, p 406-431.

[Gamma et al., 1995]

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design patterns – Elements of Reusable Object-Oriented Software. MA: Addison Wesley Longman, Inc., 1995. ISBN 0-201-63361-2

[Gamma et al., 1995a]

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Programtervezési minták. Kiskapu, 2004. [Gamma et al., 1995] fordítása.

[Gibbs, 1994]

W. Wayt Gibbs: Software's Chronic Crisis. Trends in Computing. Copyright Scientific American, September 1994; p 86

[Gill, 2000]

Tyson Gill: Planning Smarter: Creating Blueprint-Quality Software Specifications. Pearson Professional Education, 2000

[Golden, 2003]

Bernard Golden: Open Source: The Whole Product. O'Reilly Network. http://www.oreillynet.com/pub/au/1301

[Green et al., 1999]

Gina Green, Alan R. Hevner: Perceived Control of Software Developers and Its Impact on the Successful Diffusion of Information Technology. CMU/SEI-98-SR-013. Carnegie Mellon University, 1999

[Green et al., 2000]

Gina Green, Alan R. Hevner: The successful diffusion of innovations: Guidance for software development organizations. IEEE Software. November/December, 96-103.

[Harrison et al., 2000]

N. B. Harrison, B. Foote, H. Rohnert: Pattern Languages of Program Design 4. Reading. Addison Wesley, 2000

133

Angster Erzsébet: Doktori (PHD) értekezés, 2006 [Harrison, 1999]

Neil B. Harrison: The Language of Shepherding. A Pattern Language for Shepherds and Sheep. PLoP Proceedings, 1999. http://jerry.cs.uiuc.edu/~plop/plop99/proceedings

[Hay et al., 1996]

David Hay, Richard Barker: Data Model Patterns: Conventions of Thought. Reading. New York, Dorset House Publishing. 1996

[Hillside, 2003]

Hillside group, Patterns Home Page. http://hillside.net/patterns/, accessed at 10th November, 2003.

[Hiperdictionary, 2003] Hiperdictionary, 2003 at http://www.hyperdictionary.com, accessed at 10th November, 2003. [Holloway et al., 1996] C. Michael Holloway, W. Ricky Butler: Impediments to Industrial Use of Formal Methods. IEEE Computer. 29(4), 25-26. [Iivari, 1996]

Juhani Iivari: Why are CASE tools not used? Communications of the ACM. 39(10), 94-103.

[Jacobson et al, 1997]

Ivar Jacobson, M. Griss, P. Jonsson: Software reuse: Architecture and Organization for Business SuccessNew York, ACM Press, 1997.

[Karlsson, 1995]

E.-A. Karlsson: Software Reuse: A Holistic Approach. Chichester: John Wiley & Sons, 1995.

[Knuth, 1973]

Donald Ervin Knuth: The Art of Computer Programming. Addison-Wesley, 1973

[Larman, 2002]

Craig Larman: Applying UML and Patterns. Reading. Prentice Hall, 2002

[Lilly, 1996]

Susan Lilly: In: Object Magazine, 1996, January

[Longstreet, 2003]

David Longstreet: Software Productivity Since 1970. Longstreet Consulting Inc. http://www.softwaremetrics.com, Articles: http://www.ifpug.com/Articles/history.htm

[Magyar értelmező kéziszótár, 1985] Magyar értelmező kéziszótár. Akadémiai kiadó, 1985 [Manns et al., 1998]

Mary Lynn Manns, Helen Sharp, Maximo Prieto, Phil McLaughlin: Capturing Successful Practices in OT Education and Training. Journal of Object Oriented Programming, 1998, Vol. 11, No. 1, pp 29-34.

[Manns, 2002]

Mary Lynn Manns: ”An Investigation Into Factors Affecting the Adoption And Diffusion of Software Patterns in Industry” Ph.D. thesis. De Montfort University Leicester United Kingdom, Software Technology Research Laboratory, at http://www.cs.unca.edu/~manns/, accessed 10 April 2004.

[Martin et al., 1998]

Robert C. Martin, Dirk Riehle, Frank Buschmann: Pattern Languages of Program Design 3. Reading, Addison-Wesley, 1998.

[McBreen, 2002]

Pete McBreen: Software Craftsmanship: The New Imperative. Addison Wesley Longman, Inc., 2002. ISBN: 0-201-73386-2

[Meszaros et al., 1998]

Gerard Meszaros, Jim Doble: A Pattern Language for Pattern Writing. In: [Martin et al., 1998, p527-574]

[MooreGA, 1991]

Geoffry A. Moore: Crossing the chasm: Marketing and selling technology products to mainstream customers. Harper Business, New York, 1991

[MooreGC et al., 1991] Gary C. Moore, Izak Benbasat (1991) Development of an Instrument to Measure the Perceptions of Adopting an Information Technology Innovation. Information Systems Research, 2(3), 192-222 [Mowbray et al., 1997]

134

Thomas J. Mowbray, Raphael C. Malveau: CORBA Design Patterns John Wiley & Sons, 1997

12. Hivatkozásjegyzék [Norman, 1999]

Don Norman: The Invisible Computer. MIT Press. ISBN 0-262-64041-4

[OOPSLA]

Object-Oriented Programming, Systems, Languages and Applications. Annual conference. http://www.oopsla.org

[Oxford, 1986]

Oxford Számítástechnikai értelmező szótár, 1986. Budapest: NOVOTRADE. Eredeti cím: Dictonary of Computing, 1986

[PLoP]

PLoP (Pattern Languages of Programming) konferencia. http://stwww.cs.uiuc.edu/~plop/

[Portland Pattern Repository, 2003] Website. http://c2.com/ppr/ [PPP, 1996]

The Pedagogical Patterns Project. Successes in Teaching Object Technology Proto-Patterns http://www.soi.city.ac.uk/~hsharp/OopslaPATS.htm, accessed at 1st August, 2002

[PPP, 2003]

Pedagogical Patterns Project. http://www.pedagogicalpatterns.org, accessed at 20th October, 2003.

[Pressman, 2000]

Roger S. Pressman: Software Engineering: A Practitioner's Approach. Europian Edition: McGraw-Hill, Inc.

[Raymond, 1998]

Eric S. Raymond: ”The Cathedral and the Bazaar.” First Monday, volume 3, number 3 (March), 1998. at http://www.firstmonday.org/issues/issue3_3/raymond/, accessed 10 April 2004.

[Rising, 1998]

Linda Rising: The Patterns Handbook. Cambridge University Press. 1998.

[Rogers, 1995]

M. Everett Rogers: The Diffusion of Innovations, 5th Edition. e-Book. Everett Rogers, 1995

[Schneider et al., 1999] Geri Schneider, Jason P. Winters: A Review of the Current State of Practice. UML World DesignFest. White paper. http://books.txt.com/, accessed 5th November, 2002. [SDP, 2004]

http://sdp-city.hu

[Sharp et al., 2000]

Helen Sharp, Mary Lynn Manns, Jutta Eckstein: Do we Need Patterns for Pedagogy? OT Conference, Oxford, 2000

[Shaw, 1995]

Mary Shaw: Patterns for Software Architectures. In: [Coplien et al., 1995] pp 453-462

[Shaw, 1996]

Mary Shaw: Some Patterns for Software Architectures. In: [Vlissides et al., 1996]

[The Software Patterns Criteria, 1998] The Software Patterns Criteria (Version 10.2, June 2, 1998). Proposed Definitions for Evaluating Software Pattern Quality. http://www.antipatterns.com/whatisapattern/, accessed 10th November, 2003. [Tornatzky, 1982]

L. G. Tornatzky, K.J. Klein: Innovation Characteristics and Innovation Implementation: A Meta-analysis of Findings. IEEE Transactions on Engineering Management. EM-29(1), 28-45.

[Vlissides et al., 1996]

John. M. Vlissides, James O. Coplien, N. L. Kerth: Pattern Languages of Program Design 2. Reading, Addison-Wesley, 1996

[Webster, 1987]

Webster's Ninth New Collegiate Dictionary, 1987

[Webster, 1996]

Bruce F. Webster: The Real Software Crisis. The shortage of top-notch programmers threatens to become the limiting factor in software development. Byte Digest, 1996 January. http://byte.com

135

Angster Erzsébet: Doktori (PHD) értekezés, 2006

136

12. Hivatkozásjegyzék

MELLÉKLET Az internetes felmérés kérdőíve

http://sdp-city.hu/felmeres

A felmérés ideje: 2004. április Nyomtatva: 2006. április 9-én.

137