Fejlesztés – elejétől végig

Régen nagyon sok programozási nyelv született – és még ma is, bár csökkenő vehemenciával –, esetleg csak szakmai részterületek kiszolgálására. Később ezek a nyelvek már nemcsak a megoldandó feladatokra voltak tekintettel, hanem azokra is, akik használják őket. Kialakult például az objektumorientált világ és a különböző fejlesztőkörnyezetek, s egyre több szolgáltatással igyekeztek segíteni fejlesztőknek a hatékony, jó együttműködésben. S ezzel visszaértünk a problémák gyökeréhez: önmagunkhoz. Az informatikai fejlesztések

bizony embereknek készülnek, nagyon fontos tehát, hogy megtudjuk, mit szeretnének ezek az emberek, s az erről szerzett információt folyamatosan szem előtt kell tartanunk.

Az alapmódszertan a klasszikus és egyszerű esetekben az, hogy felmérjük az igényeket, elkészítjük a specifikációt, megtervezzük a rendszert, fejlesztünk, tesztelünk, és a jól végzett munka tudatában reménykedünk, hogy ezt a megrendelők is ugyanígy gondolják. Sajnos az ilyen egyszerű eset ritka, mint a fehér holló: mindig vannak nagyon is gyakorlati, tekintetbe veendő korlátok; ezeket a gyakorlati korlátokat igyekszem most végignézni a fejlesztések folyamatában.

Módszertanok röviden • Vízesés módszertan – A legrégebbi felfogás: szakaszai szigorúan elválnak egymástól, a szakaszok végén lezáródnak a termékek (dokumentumok), és csak azok szerint lehet továbbhaladni. Ez a módszertan csak régen működött, akkor, amikor a fejlesztők erősebbek voltak a megrendelőknél, és a fejlesztési cél világos volt – viszonylag tiszta, mint egy hegycsúcs. Csakhogy ma már mozognak a hegyek – egyrészt a gyorsuló verseny, másrészt a türelmetlenebb megrendelők miatt –, ezért megjelentek a kisebb, szabályozott visszacsatolások a szakaszok között, hogy fellazítsák a szigorú elhatárolásokat. Ez a módszertan használatos a leggyakrabban – egyszerűen azért, mert ha tendert írunk ki, akkor ebben a modellben lehet a legvilágosabban meghatározni, mikorra mi lesz meg és mennyiért. • Ciklikus módszertanok – Ezekben a módszertanokban csak részben igaz az a felismerés, hogy a „felhasználó tudja, mit akar”; ő is okosodik, érdemes tehát megcsinálni egy kisebb falatot, majd azt bevezetni és utána elgondolkozni a „hogyan tovább” kérdéseken. Az elmélet nagyon szép, de így kimondva ritkán jelenik meg, mert a felhasználók egyszerűen nem fogadják el, hogy az ő jövőre vonatkozó elképzeléseik sem egyértelműek. Inkább fejlesztési programokban használnak ilyen módszertant, ha nagyobb csomagokban, negyedévente vagy néhány havonta fejlesztik a rendszereket. • Microsoft Solutions Framework (MSF) – A Microsoft Solutions Framework hibridmódszertan – a ciklikus és a vízesés módszer elemeit vegyíti. Külön érdekessége, hogy csapatmodellben folyik a projektvezetés, s ez nagyon megterheli a projektvezetőket (sok vitájuk lesz), de jól kiegyensúlyozottan jelennek meg a csapattagok által képviselt érdekek. A Microsoftnál bőséges segédanyag (sablon) tölthető le. • Extreme Programming (XP) – Az Extreme Programming nagyon egyszerű szabályokkal működő módszertan; főként a nagyon kockázatos és nagyon homályos célokkal indított projektekben hasznos. Az a jellegzetessége, hogy a csapatmunkára összpontosít, a fejlesztők és a megrendelők szinte folyamatosan, kéz a kézben alakítják ki a rendszert. Fontos szerep jut benne a tesztelésnek, a rendszer felhasználhatóságának.

Igényfelmérés

Itt máris nagy akadályba ütközünk: meg kell tudunk, hogy mit szeretnének a megrendelők. A leghasznosabb persze az lenne, ha azt deríthetnénk ki, hogy mire van szükségük valójában. Sajnos ebben az előkészítő szakaszban jó pszichológusra sokkal nagyobb szükség van, mint gyakorlott programozóra, sőt a programozókat ilyenkor a legjobb távol tartani. Az alapprobléma kezelése – azé a problémáé, hogy mindenki „jót szeretne, olcsón és gyorsan” – sok mindent eleve meghatároz; de nincsen rá recept (tapasztalatok szerint ebből a hármasból kettőt lehet alapul venni).

A második legfontosabb tény az, hogy a megrendelő – mert már látott informatikai rendszert – úgy gondolja, hogy ért az informatikai rendszerek fejlesztéséhez. Ebben a tekintetben szerencsésebb a kemény meggyőzés helyett elfogadó, együttműködő, oktató pozícióban dolgozni; a legjobb az, ha gondosan pallérozzuk a megrendelőket: mire képes az informatika és mire nem.

Igen sűrűn találkozom azzal a hibás szemlélettel, amely egy informatikai rendszer hiányára vezeti vissza a szervezetlenséget. Ebből a kiindulásból vagy egy utált és rossz – „semmire sem jó” – rendszer születik, vagy a projekt zombivá alakul már a specifikáció közepén. Az ilyen természetű problémák „becsúszásakor” kénytelenek vagyunk megoldani a szervezési oldal meg nem oldott kérdéseit – sőt rendezni a rengeteg belső vitát is –, különben sikertelen lesz a rendszer. Erre mindig készen kell állnunk; nincs sok esélyünk az elkerülésére.

A legjobb az, ha kiderítjük, hogy mire van szükség. Ezt leginkább azzal érhetjük el, hogy valamiképpen szinte dolgozóvá válunk a szükséges szakterületeken – megismerjük ennek vagy annak a szakmának a szépségeit. Így sokkal nagyobb valószínűséggel ismerhetjük a tényleges szükségleteket. Ha nagy a szorítás és nincs mást mit tenni, akkor megkérhetjük a megrendelőket, hogy írják le igényeiket, de ezt csak csak mint végső megoldást javaslom. Sajnos minden szakmai területnek megvan a maga tolvajnyelve, és azt az írás csak tovább torzítja; ráadásul a megkérdezettek tényleg mindent leírnak; honnan tudnák, hogy abból mi tartozik az informatikára?

Specifikáció

Ez a vidám alkuk és a szomorú félreértések szakasza. A specifikációval kellene kialakulnia a fejlesztés tényleges tárgyának. A megrendelőnek nagyon nehéz kiolvasnia ezekből az anyagokból, hogy mire hasonlít majd az általunk készített eszköz: egyszerűen kezelhető távirányítóhoz vagy csak több hetes gyakorlatozás után használható hegymászó felszereléshez. Már az elején érdemes tehát tisztázni, hogy mit fogunk adni; nem lesz majd akkora a megdöbbenés az átadási szakaszban. Persze minél jobban tisztázva van a probléma, annál használhatóbb lesz a megoldás.

A félreértések igen szomorúak, biztosnak kell lennünk tehát abban, hogy a megrendelő valóban végigolvasta a hosszú és unalmas anyagokat és el is gondolkodott rajtuk. Erre prezentációval, kiscsoportos tárgyalással lehet őt rávenni.

Rendszertervezés

A rendszertervezésbe jó néhányan egyáltalán nem vonják bele a megrendelőket, pedig nagyon is tanácsos. Éspedig azért, mert ha valaki nagy vonalakban tisztába jött a rendszer felépítésével, akkor később sokkal jobban hozzáigazíthatja a maga elgondolásait. Azon nemigen döbben meg senki, hogy az autóban a botváltót drága és nehéz dolog kormányváltóvá átalakítani, egy informatikai rendszer megítélésében ez hétköznapi eset („csak rakjátok át oda azt a gombot”). Másrészt nagyon hasznos a megrendelőnek, ha látja a rendszer hosszú távú (stratégiai) képességeit és tekintetbe veendő határait.

A rendszertervezést a fejlesztők sokszor el is rejtik a megrendelők elől, s így senki sem leplezheti le a határidőnyomás vagy költségspórolás miatt elkövetett turpisságokat. Azok a rendszer belsejében és továbbfejlesztésében majd később okoznak gondot, rövid távon azonban vitathatatlanul megtérülnek.

Ehhez a szakaszhoz szinte minden fejlesztőeszközben vannak hasznos funkciók, ezt nem is vitatom, a használatuk azonban többnyire esetlegesnek tűnik. Az emberben kétségek támadnak aziránt, hogy a fejlesztők előbb sokat törték volna az agyukat azon, hogyan érdemes építkezni, csak utána fogtak bele a kódírás lassú, nehéz és bonyolult munkájának. Senki sem vonja kétségbe, hogy a bonyolultabb közgazdaságtani modellek nélküli tervezés is megtérül és hasznos, de a gyakorlatban ez a rész ritkán hoz eredményeket. Sokan a régi iskolára esküsznek: a legjobb módszertan elővenni papírt, ceruzát, és tiszta fejjel gondolkozni.

Fejlesztés

Ez a leginkább ködbe vesző művelet: „furcsa nyelven beszélő emberek furcsa dolgokat művelnek, és megszűnik létezni az idő fogalma”. A fejlesztői munka egyfelől elmélyülést és magányt kíván, másrészt szoros együttműködést a többiekkel. A fejlesztés sokszor azon csúszik meg, hogy a fejlesztők bármit képesek kifejleszteni – és mások megkérdezése nélkül meg is teszik. Alighanem azt a legnehezebb észrevenni a fejlesztés szakaszában, hogy az éppen kifejlesztendő funkcionalitás valahol, hasonló formában már megvan egy gyári, rendelkezésre álló szoftverben. Ezt a vizsgálatot tudatosan vagy öntudatlanul igen gyakran elkerülik, mert sűrűn akad olyan, már kész, megvásárolható komponens, amelynek a felhasználása sokkal több bajjal jár, mint egy új komponens kifejlesztése. S ilyen tapasztalatok után kinek volna kedve megint ilyen gondot a nyakába venni.

A dolgot az is nehezíti, hogy a megvehető komponensek minőségéről vajmi keveset tudni: a szoftveripar még fiatal, emiatt nincsen olyasfajta minősítés a szoftver dobozára ragasztva, hogy „megfelel az MSZ-xxx dokumentálási követelményeinek”, „tesztelése arany fokozatot kapott az XYZ minőség-ellenőrző cégtől”, „a szoftver biztonsági minősítése ťAŤ kategóriájú az EU szabványai szerint”. Amíg ezek megszületnek, nincs más, csak a piaci módszer: megkérdezzük az ismerősöket, hogy náluk ez vagy az hogyan vált be, illetve magunk tesztelünk.

A fejlesztésben valami nagyon szép vagy nagyon csúnya dolog születik: a forráskód. Ez a kód olyan, mint a sodronyszálak alkotta drótkötél: minél rendezettebb, annál többet fog bírni. Minél „szebb” a kód, annál könnyebb lesz hibát keresni benne és továbbfejleszteni. A „kódszépséget” nehéz jól definiálni, mert olyan fogalmak kellenek hozzá, mint érthető, strukturált, áttekinthető, megjegyzésekkel jól ellátott; és ez csak úgy érhető el, ha egy tapasztalt, öreg fejlesztő rendszeresen – naponta (!) – megnézegeti a fiatalok munkáját és oktatja őket.

Tesztelés

Ezt a szakaszt nehéz megszeretni, másfelől ez az utolsó lehetőség arra, hogy ne az éles rendszerben kelljen majd a káoszt felszámolni. Egy-egy összetettebb rendszer tesztelése nagy előkészületekkel jár, és már az előkészületekben is rengeteget lehet hibázni, mivel még a felhasználók sem tanulták meg a rendszer működését. Roppant kétségbeejtő lehet, ha a feltárt hibák jó része a rossz paraméterezésből, rossz dokumentációból, rossz használatból, rossz rendszerkörnyezetből fakad. Nincs más út: csak a szigorú, aprólékos tesztelés és hibajegy-dokumentálás adhat megoldást. S ha elkezdenek visszaszorulni a hibák, abból végre erőt meríthet a kifáradt tesztelőcsapat. A tesztelés ellenőrzésére jó fogás a szándékosan bevitt hibák kerestetése; ezt tömegesen alkalmazták a 2000. év problémájának megoldásában.

Lehet persze beszerezni (esetleg belső munkával kifejleszteni) tesztelőrobot-szoftvereket. Jó eredményekre lehet velük jutni, de nagy erő kell a bejáratásukhoz és megismerésükhöz is.

Átadás

Rendszerint már teszteléskor előjön, hogy megvannak-e a megfelelő dokumentációk; s az átadásban épp arról megy az alkudozás, mi értendő azon, hogy „megfelelő”. Nehezebb esetekben az is kérdés, hogy a szoftverhez jár-e egyáltalán dokumentáció? Az oktatást magukra vállalhatják a fejlesztők, de az üzemeltetés, a felhasználói kézikönyv elkészítése inkább a megrendelő dolga; a fejlesztői dokumentációhoz és a rendszertervhez viszont semmi köze, merthogy az a fejlesztés része. Utólag ezeket a kérdéseket is nehéz kezelni, ám ha már a fejlesztés elejétől dolgozunk rajta, akkor – mint egy jó házasságban – a két félnek hasznos megállapodás érhető el.

Itt az a kiindulópont, hogy kinek, milyen képzettségűeknek íródnak a dokumentumok. Ha ebben megegyeztünk, mindjárt könnyebb lesz a további részleteket megfogni.

Zárszó

Fejlesztési módszertanokat tömegesen szerezhetünk a világhálóról és a könyvesboltokból. A módszertanok egyébként elkezdtek szakterületekre specializálódni. Ha kisebb (20-30 fő alatti) méretekről van szó, akkor ne akarjunk mindenestül módszertanokat bevezetni, tekintsük őket inkább amolyan étlapnak, amelyen nagyon finom fogások vannak felsorolva, de nem kell mindet végigenni. Nagyon hasznos lehet, ha be olyan szakértőt vonunk be, aki már gyakorlatban is használta a kérdéses módszertant, és pontosan tudja, hogy milyen buktatói vannak.