Hirdetés
 

A rendszertervező

PDF
Nyomtatás

 

1 Bevezetés

Rendszertervező, avagy szoftver architekt - napjainkban divatos fogalom informatikai berkekben, mégis sokan rosszul- vagy félreértelmezik. Cikkünkkel igyekszünk bemutatni ennek a - kifejezetten technikai jellegű - szerepkörnek a jellegzetességeit, illetve remélhetőleg sikerül eloszlatni néhány tévhitet is egyben.

2 A rendszertervezői szerep

Az informatika egy fiatal, folyamatosan fejlődő tudomány és iparág is egyben. Ennek köszönhetően a fogalomtára nincs minden szempontból kikristályosodva, ami időnként félreértésekhez, félreértelmezésekhez vezet. Ebben a cikkben a rendszertervezői szerepkört - angolul „architect", illetve „software architect" - szeretnénk bemutatni.

A szoftverek a programozási nyelvek és módszertanok fejlődésével egyre összetettebbé váltak. Azonban nem csak a megvalósítható feladatok palettája bővült - a többrétegű alkalmazás-modell, illetve az objektum-orientáltság térhódítása megnövelte a megoldási lehetőséget számát is.
Ugyanazt az alkalmazást többféle módon is meg lehet írni, és a módszer kiválasztását - rossz esetben - csak az „elsőre-ez-jutott-az-eszembe" mondattal magyarázzuk. A fejlesztők különböző megoldásokkal rukkolhatak elő, ami nem minden esetben bizonyul a leghatékonyabbnak. Időnként nem optimális megoldások születtek, vagy éppenséggel újraimplementáltak olyan funkcionalitást, amire már létezett megoldás.

Megjegyzés
A spanyolviaszt újrafeltalálásának egyik klasszikus példája C++-berkekben a saját dinamikus tömbosztály-, vagy saját rendező algoritmus fejlesztése. A C++ szabványos sablonkönyvtára (STL) többek között ezeket is tálcán kínálta, mindössze használni kellett. Az STL vitathatatlan előnye, hogy egy letesztelt, szabványos segédkönyvtár - szemben a saját implementációval, ahol mindig megvan a kellemetlen meglepetés esélye.

A probléma a projectben résztvevő fejlesztők különböző programozási szokásaiból-, illetve eltérő technológiai ismereteiből fakadt. Megoldásként bevezették a rendszertevezői szerepkört; az ő kezében futottak össze a fejelsztéssel kapcsolatos szálak - ezt a témakört a későbbiekben részletesen kifejtjük.

A rendszertervező egyre divatosabb címmé vált az utóbbi években, és hazánkban is egyre elterjedtebb. Sok informatikai cég ezzel a szerepkörrel honorálja azokat, akik megfelelően szerteágazó tudásra tesznek szert, átlátják az alkalmazott szoftvertechnológiákat, és hatékonyan ötvözik a projectek fejlesztésekor. Egy cég tahát dönthet úgy, hogy valakinek megadja ezt a szerepkört, azonban az ehhez tartozó felelősségi körök nincsenek kőbe vésve. Valójában nincs rá pontos definíció, hogy mit is csinál egy architekt, emiatt ez cégről cégre eltérhet.

Megjegyzés
A rendszertervezői státusz népszerűsége és elterjedése állítólag Bill Gates-nek köszönhető, aki egy napon bejelentette, hogy lecseréli az addigi „President of CEO" címet a „Chief Software Architect" titulusra. Az új szerepkör jobban kifejezte azt, hogy Gates átlátja a Microsoft szerteágazó projectjeit és technológiáit. A „Vezető Szoftver Tervező" talán kissé fellengzősen hat - viszont lényegesen több szakmaiságot tükröz, mint a „vezérigazgató elnök" cím.

3 A rendszertervezői munkakör

A rendszertervező dolgozhat egymagában, teljes idejét ennek a szerepkörnek szentelve. Nem ritka azonban az sem, hogy a tervezői munka mellett belefolyik a tényleges fejlesztésbe is, esetleg projectvezetőként, rendszerelemzőként, üzleti elemzőként is tevékenykedik.
Bár cikkünkben elsősorban a project architekt szerepkört részletezzük, megemlítenénk, hogy nagyobb informatikai cégeknél találkozhatunk az architektek hierarchikus szerveződésével.

Ebben a modelleben a rendszertervezők különböző rétegekben helyezkednek el, és ennek megfelelően eltérő absztrakciós szinten dolgoznak.
Egy nagyvállalatnál például könnyen elképzelhető az alábbihoz hasonló osztályzás:

  1. Project Architekt
    A futó project tényleges problémáira összpontosít, és általában aktívan részt vesz a kódírásban is. Az általa készített tervek részletessége project-specifikus, és általában nagyon részletes - hiszen ezen tervek alapján történik a fejlesztés. A részletesség attól is függ, mennyire érett a csapat, és az esetleges fluktuációt is figyelembe kell venni (nem ismerhetjük előre az esetleges új csapattagok felkészültségét, szakirányú, illetve technológiai ismereteit).

  2. Program Architekt (Solutions Architect)
    Általában csapatban dolgoznak, és különböző technológiai újításokat vezetnek be; problémák megoldásait keresik, az időközben felmerülő igények-, illetve a magasabb szintről érkező javaslatok alapján. Egyszerre több projecttel is együttműködnek, általában a megfelelő project architekten keresztül. Az elkészített terv megfelelő részletességű kell legyen ahhoz, hogy a project architectekhez eljuttassa az információt.

  3. Enterprise Architekt
    Vállalati architekturális irányelveket szabnak meg, elvontabb formában. Általában stratégiai döntések meghozataláról van szó, amelyek az informatika és az üzlet összehangolását célozzák meg. Ez esetben ne számítsunk részletes specifikációkra, illetve tervekre. Ezen az absztrakciós szinten nem történik interakció a forráskóddal.

Megjegyzés
A fenti tagolódásban jól követhető a három, lényegesen eltérő absztrakciós szint: a project architekt van a legközelebb a kódhoz - bár mindennapi munkáját nem elsősorban a kódolásnak szenteli. A skála másik végén az Enterprise Architekt található.
Minél távolabb kerülünk a tényleges, projectszintű gondoktól, annál nagyobb a veszélye az „Ivory Tower Architects" jelenségnek. A kifejezés arra utal, hogy az elefántcsont toronyban eszigetelődve az ember nem érti meg kellőképpen a valós igényeket, és nem is állít elő valódi, felhasználható értéket, csak nagyon elvont, a valóságtól elrugaszkodott elméletet. A jelenség elkerülhető a hatékony, kétirányú kommunikációval. El kell kerülni, hogy az információ ne csak „ukázként" utazzon a felsőbb architektúra szintektől lefele, hanem akár project szintről is lehessen visszajelezni.

4 Architekturális feladatok

Mint említettük, valójában nincs pontos definíció arra, hogy milyen felelősségei vannak egy rendszertervezőnek. Mindazonáltal létezik néhány feladat, amelyek nélkül nehezen elképzelhető egy architekt munkája.
A főbb felelősségi körök:

  1. A fejlesztéskor alkalmazható lehetőségek leszűkítése
    A cél eléréséhez az architekt szabályrendszereket határoz meg - ilyen például a rendszerterv, de például az egységes elnevezési és kódolási konvenció-, a részletes hibakezelési útmutató-, vagy az alkalmazandó kivételhierarchia definiálása is ide tartozik. Ezenkívül az ő felelőssége a megfelelő keretrendszer létrehozása vagy kiválasztása, amely az alkalmazás alapját képezi.

  2. Újrafelhasználhatóság kiaknázása
    A tervező feltárja a számításba vehető, újrafelhasználható technológiákat, komponenseket, alkalmazásokat, amelyek - például egy másik projectből - átvehetők. Ezáltal elkerülhető annak a bizonyos spanyol viasznak a feltalálása, és jelentősen lerövidülhet a fejlesztési idő.
    Ehhez persze jó rálátással kell rendelkeznie a többi projectre - ehhez elengedhetetlen a kommunikáció a többi project-tervezővel, esetleg a Program Architekt (lásd: Solution Architects) csoporttal.

  3. Alkalmazásterv elkészítése
    A tervező egyik legérdekesebb feladata talán a terv elkészítése. A folyamat általában egy elnagyolt tervvel kezdődik, amit folyamtosan lebontunk, majd továbbfinomítunk. A tervből kibontakozik az alkalmazás statikus és dinamikus nézete is, nyomon követketők az alkotóelemek, komponensek közötti függések és interakciók. Az így elkészülő tervek akár a metódusszintű részletességet is elérhetik - azonban erre nincs mindig szükség.
    A terveket általában valamilyen formális ábrázolónyelv segítségével készül el. A szabványos megoldást az UML jelenti, azonban ennek léteznek különféle cégspecifikus-, adaptált verziói is.
    Végezetül a csapat megkapja a terveket, és elkezdődhet a fejelsztés.

  4. *Az alkalmazással szemben támasztott követelmények letisztázása is az architect feladatkörébe tartozhat. Ez esetben az ő feladata kommunikálni a megrendelővel (esetleg közvetett csatornákon - úgynevezett „Solution Manager"-eken - keresztül). A feladat ilyenkor az üzleti igényeket szoftveres követelményrendszerré alakítani, ami általában nem egyértelmű.

A tervező sok esetben kikérheti a fejlesztők véleményét, és azok hozzájárulásával, illetve beleegyezésével alkotja meg a szabályrendszereket és a terveket. A különböző lépések során bevonhatja a csapatot, illetve azokat a fejlesztőket, akik egy speciális terület implementálásáért felelősek.

Az architekt és a csapat szempontjából is nagyon hasznos a kétirányú kommunikáció.
Az alkalmazás architektúrája menetközben változhat - például új igények felmerülésekor. Az agilis módszertanok esetében a változás kifejezetten része a módszertannak. Ilyenkor a tervet is „utána kell húzni", hogy valóban az aktuális képet mutassa.

5 Zárszó

A szoftvertervezőnek rendelkeznie kell egy viszonylag részletes felülnézeti képpel a készülő alkalmazásról. Emellett behatóan ismernie kell a szoftverkörnyezetet, az egymással kapcsolatba kerülő rendszereket, valamint az alkalmazott technológiákat, hogy azokat a lehető legoptimálisabban alkalmazhassa.
A stratégiai gondolkozás és a felmerülő problémák idejében történő felismerése szintén olyan erények, amelyek sikeressé tesznek egy rendszertervezőt.

Ergo szakmai és személyiségbeli kvalitásokra egyaránt szükség van ahhoz, hogy valakiből jó szoftvertervező lehessen. Ha ezekkel nem rendelkezik valaki, előbb utóbb úgyis kiderül.

A szerző rendszertervezőként dolgozik a SAP Labs HU Suite Composite Development részlegénél.
Szakírói tevékenységét nem most kezdte - eddig számos cikke és két szakkönyve jelent meg.

További cikkek a szerzőtől


Téma megvitatása (1 hozzászólás)
A rendszertervező
2012. November 30. péntek, 12:23
Ebben a témában a következő cikket vitatjuk meg: A rendszertervező

Értékesítőink megérkeznek a nagy üzlettel: adott egy komplex fejlesztési feladat egy külső megrendelő részére.
A scope, a határidő és a költség elég rugalmas még.
A megrendelői környezet hw, sw és ow komponenseinek feltérképezését követően az elvárt megoldásra tesz javaslatot az architect - őt régen simán rendszerszervezőnek hívták.
Feladatai: a megrendelő által kívánt környezetben esetleg a megrendelő által elvárt technológiákkal megvalósítani a megrendelt fejlesztési feladatot.
Erre készítenek ő, a PM, illetve a vezető fejlesztő és adatbázis tervező egy olyan nagyvonalú rendszertervet, amely szerintük megvalósítható az adott erőforrásokkal és hw, sw, orgware eszközökkel adott idő alatt.
Ha létrejön az üzlet ő lesz aki részletesen megtervezi a szállítandó megoldás elemeit és olyan szinten dokumentálja, hogy abból már kódot lehet iratni a fejlesztőkkel db fejlesztőkkel. Az átállásokat, migrációkat, folyamatszintű változtatásokat is ő tervezi meg. A PM ezeket mindig átnézi és a hiányosságokat keresi bennük. A PM itt arra fókuszál, hogy nem hagytunk-e ki valamit, mindenre gondoltunk. Ha van külön minőségbiztosító, tesztcsapat vezető, kockázatkezelő, akkor ők, ha nincs akkor a PM már ekkor azt nézi, hogy be vannak tervezve a megfelelő megoldások? Ha hiányoznak a PM megtervezteti ezeket is az architekttel.
PM ekkor már ész nélkül, erőforrásigényt, rendelkezésre álló forrásokat, projekt költségeket, milestonokat és tartalékidőket számol. Már ekkor ismeri a key usereket és azonosította a stakeholdereket. Pm kiemelten figyel rá, hogy az architekt személyét és terveit IS fenntartás nélkül elfogadja a megrendelő, hiszen az architekt álatal tervezetteket fogják megalkotni a PM emberei a megrendelő költségére.

A téma megvitatása a fórumon. (1 hozzászólás)