INFOKOMMUNIKÁCIÓ FEJLESZTÉSI MÓDSZERTAN A követelményspecifikáció szerepe az informatikai projektekben Dr. Surján György, Dr. Szabó János, Országos Vérellátó Szolgálat A szerzők az informatikai projektek gyakori sikertelenségének egyik jelentős okára, a nem kellő gondossággal készített követelményspecifikáció következményeire hívják fel a figyelmet. Az általános elvárásokon túl a pontos, mindenre kiterjedő és ellentmondásmentes követelményspecifikáció jelentőségét hangsúlyozzák, a specifikáció elkészítésének többféle lehetséges módját mutatják be. Mondanivalójuk illusztrálására az Országos Vérellátó Szolgálat informatikai fejlesztési feladataiból vesznek példát. erőforrásokat biztosítva, a felelőségeket és határidőket nevesítve és az eredményességet ellenőrizve hajtják végre. BEVEZETÉS Az Országos Vérellátó Szolgálat 1998-2000 között jött létre, az Országos Vérellátó Központ (OVK) és 27 kórházi vérellátó osztály integrációja révén. A szervezeti átalakítás egyértelmű célja az volt, hogy a regionális hierarchiába szervezett rendszerben a vérkészítmények előállítása regionális központokba centralizálódjon. Csak így lehet ugyanis biztosítani, hogy a feldolgozás az európai minőségi elvárásoknak megfelelő, korszerű berendezések segítségével történjen. Az informatikai rendszerek szükségességét az egészségügyi intézmények vezetői ma már ritkán vonják nyilvánosan kétségbe. Sokan mégis azt látják, hogy nagy anyagi ráfordítás ellenére kevés az eredmény, sok a bosszúság. A szkepszis nem alaptalan. Nemzetközi tapasztalatok szerint az informatikai projektek ijesztően nagy (70-90!) százaléka sikertelen: vagy a tervezett költség ill. időkeretet lépi túl jelentősen, vagy a megvalósuló funkcionalitás marad el a várttól. A teljes kudarc sem ritka. A buktatók elkerülésére számos módszertant (pl. SSADM [1], RUP [2]) dolgoztak ki, azonban a gyakorlatban aligha létezik egyetemesen üdvözítő módszertan, ezért ezek megfontolt hasznosítását javasolhatjuk csupán. Ebben a cikkben az egészségügyi intézmények informatikai projektjeinek néhány kritikus kérdését próbáljuk összefoglalni, példának hozva föl az Országos Vérellátó Szolgálat (OVSZ) előtt álló informatikai feladatot. Nem vállalkozhatunk arra, hogy az informatikai projektek sikerét befolyásoló minden tényezőre kitérjünk, csupán arra, hogy rávilágítsunk néhány kritikus pontra. Néhány szót még szóljunk bevezetésképpen arról, hogy mit tekintünk informatikai projektnek. A kifejezésen olyan új rendszer bevezetését – vagy a meglévő rendszerek átalakítását – értjük, amely egy adott intézményben vagy annak valamely részlegében a munkakörülményeket lényegesen megváltoztatja. A projekt mérete lényegében közömbös: akkor is projektről beszélünk, ha az adott intézményben három ember munkáját érinti, feltéve, hogy a munkavégzésben lényeges a változás. Az is közömbös, hogy az adott intézményben a változtatást projektszerűen kezelik-e vagy sem. Projektszerű kezelésen azt értjük, hogy a változtatást tudatosan, szükségességét és következményeit felmérve, az A VÁLTOZTATÁS SZÜKSÉGESSÉGE Nincs olyan informatikai rendszer, amely minden igényt kielégítene. A teljes megelégedettség hiánya tehát nem elég érv ahhoz, hogy belefogjunk egy informatikai fejlesztésbe. Csak az adott intézmény alapvető céljaiból kiindulva lehet dönteni arról, hogy szükséges, és lehetséges-e a változtatás. Az OVSZ esetében a helyzet a következő: Az átszervezéssel egyidőben megfogalmazódott egy olyan integrált rendszer igénye, amely a vérellátási, a gazdasági, a logisztikai és az irányítási folyamatokat egyaránt kiszolgálja. A változás szükségessége tehát abban foglalható össze, hogy a korábbi rendszerek nagyrészt információtechnológiai szempontból elavultak, a szigorodó minőségügyi elvárásoknak, és az országos hierarchikus szervezeti struktúrának nem feleltek meg. A meglévő informatikai rendszerek megtartása azt jelentené, hogy a lezajlott szervezeti átalakítás nem érné el a célját. Ha az informatikai rendszer adottságai az intézmény alapvető céljainak elérését jelentősen korlátozzák, akkor nyugodtan mondhatjuk, hogy a változtatás szükséges. Fordítva is igaz: nincs értelmes informatikai projekt, ha az intézmény alapvető céljai nincsenek világosan megfogalmazva. KULCSKÉRDÉSEK Előfordul, hogy ugyanannak a szoftver-nek a bevezetése az egyik intézményben sikeresen történik, a másikban hasonlóban pedig kudarcot vall. A siker csak kis részben múlik a szoftver kiválasztásán. A sikernek két gyakran emlegetett kulcstényezőjét szeretnénk kiemelni: IME I. ÉVFOLYAM 3. SZÁM 2002. OKTÓBER 25 INFOKOMMUNIKÁCIÓ FEJLESZTÉSI MÓDSZERTAN Az egyik az emberi tényező: mind a szállító, mind a megrendelő (felhasználó) munkatársainak pozitív hozzáállása. A másik tényező az elvárások pontos és világos megfogalmazása. A következőkben azt igyekszünk megmutatni, hogy a két tényező szorosan összefügg. Az emberi tényező Minden ide vonatkozó tankönyv azt mondja, hogy világos intézményi stratégia nélkül nem lehet sikeres informatikai projektet végrehajtani. A tétel önmagát bizonyítja: az informatika ugyanis sosem lehet öncél, csak valami másnak a szolgálata. Az emberi tényező az intézmény oldaláról elsősorban azt jelenti, hogy eltökélt vezetőkre van szükség, akik számára az intézményvezetés tudatosan megfogalmazott célok elérésére irányuló alkotó munka. Az emberi tényező fontossága azonban nemcsak a vezetőkre, hanem valamennyi dolgozóra vonatkozik. A felhasználók negatív hozzáállása a legelszántabb vezető munkáját is tönkre teheti. A negatív hozzáállást pedig nem lehet valamilyen morális kérdésként kezelni. Egy informatikai rendszer bevezetése mindig nagy terhet ró a dolgozókra. Az egyik elengedhetetlen feltétel, hogy mindenki előre lássa a rendszer előnyeit. Ezek azonban sokszor csak évek múltán realizálódnak igazán. Hogyan lehet az informatikai szempontból többnyire laikus felhasználóknak az előnyöket előre megmutatni? Szerencsés esetben pl. el lehet vinni őket egy másik hasonló intézménybe, ahol jól működő rendszer van. Ez azonban általában csak az érintettek kis hányada számára szervezhető meg. Az OVSZ esetében nem járható, mert nincs más hasonló intézmény. Az egyetlen megoldás, ha pontosan és részletesen kidolgozott követelményspecifikáció készül, amely modellszerűen megmutatja, hogy mit kell a megvalósítandó rendszernek nyújtania. Léteznek ma már olyan rendszermodellező megoldások, amelyek – minden egzaktságuk mellett – a rendszert képesek valamennyire szemléletessé tenni. Majdnem úgy, mint amikor valaki házat építtet, és elvárja a tervezőtől, hogy ne csak laikusnak értelmezhetetlen műszaki rajzokat készítsen, hanem szemléletes rajzokon mutassa be, milyen is lesz a háza. Talán még nehezebb a szállító munkatársainak megfelelő hozzáállását garantálni. Természetesen a megbízás elnyeréséig minden szállító meggyőző érvekkel bizonygatja, hogy semmi nem fontosabb neki, mint a vevő megelégedettsége. Szerződéskötés után azonban az üzletkötők átadják a terepet a projektmenedzsernek, akiből sokszor a szerződésben vállalt kötelezettségeket se könnyű kivasalni. Ebben nem valamiféle tisztességtelen üzleti magatartást kell látnunk, hanem a mai informatikai piac sajátosságait. Ez a piac ugyanis egyszerre kínálati – mert nagyon sok cég igyekszik megélni belőle – és ugyanakkor keresleti, mert világszerte kevés a jól képzett fejlesztő, programozó. A cégek közötti kemény versenyben tehát csak az tud megmaradni, aki alacsony áron ígér jó szolgáltatást, melyet a valóságban viszont a szakemberhiány miatt csak nehezen tud teljesíte- 26 IME I. ÉVFOLYAM 3. SZÁM 2002. OKTÓBER ni. A rosszul definiált fejlesztési feladatról pedig többnyire az derül ki, hogy a valóságban sokkal bonyolultabb, mint amilyennek látszott. A helyzet különösen veszélyes az egészségügyi intézmények esetében. Itt ugyanis az általános pénzhiány miatt az intézmények könnyen kötnek szerződést nyomott áron, még akkor is, ha az a korrekt teljesítéshez biztosan nem elegendő. Az a kérdés tehát: mit lehet tenni annak érdekében, hogy az ajánlati ár ellenértékeként valóban olyan megoldást kapjunk, amivel a megrendelő elégedett lehet. A szerződéskötés után gyakorlatilag semmit. Minden azon múlik, hogy előtte világosan, egyértelműen és számonkérhetően mondtuk-e meg, amit várunk. Ha igen, akkor a szállító is tudja mihez tartani magát, reálisabb árajánlatot is tehet, és a megfelelő erőforrásokat is jobban tudja biztosítani. S ebben az esetben már tényleg neki is érdeke, hogy a vevő elégedett legyen, tehát mindent meg is fog tenni ennek érdekében. Hiszen ha a világos feltételeknek nem felel meg, akkor könnyen el is veszítheti az üzletet, és a rossz referenciát is igyekszik elkerülni. Mit kell elvárni az informatikai szolgáltatótól? Az egészségügyi intézmények informatika fejlődésének kezdetén a számítógép beszerzése jelentette az első és utolsó kérdést. Hamar kiderült, hogy programok nélkül a számítógép semmire se használható. Szoftver piac hiányában programozókat kezdtek alkalmazni, saját fejlesztésű programokat használni. Később a szoftver gyártás ipari jellegűvé vált, ma már szigorú technológiai szabályokat, drága de roppant hatékony fejlesztő eszközöket követel. Ezeket a feltételeket csak olyan cégek képesek biztosítani, amelyek szoftver gyártásból élnek. Ezért jött el a szoftver vásárlás kora. De ez sem az utolsó fejezet. Manapság egészségügyi intézményeinkben épp az a gyakori hiba, hogy az informatikai probléma megoldását szoftver-vásárlássá egyszerűsítik. Ez esetben a szállító valamilyen szerződés konstrukció szerint átadja a terméket, esetleg elvégzi a betanítást, és megkapja a szerződés szerinti ellenértéket anélkül, hogy bárki meggyőződne arról, hogy szoftver beszerzése megoldotta-e az a problémát, ami miatt a beszerzést kezdeményezték. Ilyenkor gyakori érv, hogy ez a szoftver más intézményben – netán más országban – már sok helyen bevált, biztos nekünk is jó lesz. Egészségügyi hasonlattal: ha beadunk egy betegnek valamilyen gyógyszert, mert másoknak bevált – ebből a legkevésbé sem következik, hogy a beteg tényleg meggyógyul. Pedig a cél nyilván nem a gyógyszer beadása, hanem a gyógyulás. A szoftver beszerzése nem azonos a probléma megoldásával. Az információrendszer feladata úgy fogalmazható meg, hogy az adott intézmény minden dolgozója kellő időben, megfelelő helyen és megfelelő formában megkapja a INFOKOMMUNIKÁCIÓ FEJLESZTÉSI MÓDSZERTAN munkájához szükséges valamennyi információt. Ez persze részekre bontható, egyes részlegek, munkafolyamatok informatikai támogatása önmagában is szükséges lehet. Stratégiai kérdés, hogy átfogó (divatos de többnyire pongyolán használt szóval integrált) megoldásra törekszünk, vagy jól kezelhető körülírt problémára keresünk megoldást, amit majd legföljebb később integrálunk egy teljes megoldásba. Az OVSZ-ben ilyen körülírt probléma pl. a gyógyszer-igények, tenderek és beszerzések követése. Akár átfogó, akár részmegoldást keresünk, mindenképpen arra kell törekedni, hogy az informatikai szolgáltató a megoldást nyújtsa, nem pedig valamilyen terméket. Ma már az informatikai cégek jelentős része felkészült arra, hogy hardver vagy szoftver eladás helyett ilyen megoldás-szállítói szolgáltatást biztosítson, reális áron. Hiba, ha az intézmény maga próbálja a megoldás eszközét megkeresni. Ezzel ugyanis szűkíti a versenyt, hozzáköti magát valamilyen konkrét eszközhöz, holott nem magára az eszközre van szüksége, s lehet, hogy más, sokkal jobb megoldás elől elvágja az utat. Ehelyett ki kell használni azt, hogy az informatikai piacon a cégek között erős verseny van, a problémát kell megfogalmazni, és hagyni a lehetséges szolgáltatókat, hogy felvonultassák a lehetséges eszközök minél szélesebb fegyvertárát. Ahhoz azonban, hogy reális ajánlatokat versenyeztethessünk, nem elég a megoldandó problémát általánosságban megfogalmazni. Ekkor ugyanis az ajánlattevők csak hozzávetőlegesen tudják a feladatot megbecsülni, s vagy felülbecsült árral túlbiztosítják magukat, vagy irreálisan alacsony árral igyekeznek a konkurenciát legyőzni. Mindkét eset rossz. Az elsőt nem kell magyarázni, a második esetben pedig vagy időben fog nagyon elhúzódni a projekt, vagy csak egy része fog megvalósulni annak a funkcionalitásnak, amit el akartunk érni. Mielőtt bemutatnánk, hogy mi mindenre kell kitérni a feladat megfogalmazásakor, vizsgáljuk meg, hogy kire lehet bízni a részletes, pontos és számonkérhető követelményspecifikáció elkészítését. KI KÉSZÍTSE EL A KÖVETELMÉNYSPECIFIKÁCIÓT? Erre a kérdésre három lehetséges válasz van: 1. A követelményspecifikáció készítése a rendszerfejlesztés része, ezért annak kell végeznie, aki a rendszert kifejleszti. A megrendelő szakemberei csak átadják az ehhez szükséges szakmai információkat, és a szolgáltató által készített követelményspecifikációt a megrendelő felelős vezetői jóváhagyják. 2. A követelményspecifikáció tartalmazza az intézmény összes elvárását, ezért azt saját szakemberekkel kell készíttetni, akik jól ismerik az intézmény belső folyamatait, tevékenységét és felépítését. 3. A követelményspecifikáció készítése külön jártasságot igényel, amellyel az intézmények informatikusai általá- ban nem rendelkeznek, a szolgáltatóra bízni viszont a részbeni érdekellentét miatt nem lehet. Ezért a munkát ebben jártas harmadik félre kell bízni. Az első megoldás előnye, hogy a feladatmegfogalmazás jól fog illeszkedni az alkalmazott szoftver technológiához. Hátránya, hogy kevésbé fog illeszkedni az intézmény céljaihoz, több kompromisszumot kell kötni. Olyan esetben ajánlható, amikor a feladat nem átfogó, többé-kevésbé típusos és az intézmény nem rendelkezik ilyen feladatra képes saját szakemberrel. A második megoldás előnye, hogy az intézményi célok legjobb kiszolgálásához vezethet, nem igényel extra forrásokat. Hátránya viszont hogy aránylag időigényes. Veszélye lehet még, hogy a követelmények túlzottak, reális áron nem teljesíthetők lesznek. Speciális ismereteket igénylő, bonyolult, az egész intézményt átfogó probléma megoldása esetén javasolható. A harmadik megoldás kiegyensúlyozott középutat jelenthet a technikai realitás és az intézményi célok szolgálata között. Elvben gyorsabb lehet, mint a saját szakemberekkel való munka, de a szakmai tevékenység megértése valószínűleg felületesebb lesz. Hátránya, hogy külön forrást igényel, az ilyen feladatra felkészült szakemberek között kevés van, aki független minden informatikai szolgáltatótól és képes az intézményi célok maradéktalan szolgálatára. Mindhárom megközelítésnek van tehát létjogosultsága és általánosan üdvözítő megoldás nincs. A három módszer vegyíthető is, pl. a belső csapat által készített követelményspecifikációt akár a szállítóval, akár harmadik féllel lehet tökéletesíteni, majd azt a megrendelő szakembereivel véglegesen elfogadtatni. A döntést a konkrét helyzet ismeretében kell meghozni. Az OVSZ stratégiájában azt fogalmaztuk meg, hogy a követelményspecifikáció készítése elsődlegesen belső feladat, amelyet az OVSZ informatikusai és vérellátási szakemberei közösen készítenek el. Ennek a választásnak az volt az oka, hogy a vérellátás sajátos tevékenység, amelynek részletes megismerése külső szakemberek számára hosszú időt vesz igénybe, ezért akár a szolgáltató, akár harmadik fél csak nagyon nagy költség és időráfordítással lenne képes jól megoldani a feladatot. HOGYAN ÁLL ELÔ A KÖVETELMÉNYSPECIFIKÁCIÓ? Az üzleti modell Ha az informatikai fejlesztéstől az intézményi tevékenység meghatározott módon történő segítését várjuk, akkor a kiszolgálandó működést be kell mutatnunk. Ezt az úgynevezett „business modell” segítségével tehetjük. Ideális eset volna, ha az üzleti modellt úgy készíthetnénk el, hogy az intézmény még nem is létezik. Ekkor az informatikai rendszer tervezésével egyidőben tervezhetnénk meg az üzleti folya- IME I. ÉVFOLYAM 3. SZÁM 2002. OKTÓBER 27 INFOKOMMUNIKÁCIÓ FEJLESZTÉSI MÓDSZERTAN matokat, s közel optimális működést lehetne elérni. A valóságban azonban legtöbbször az intézmény már valahogyan működik. A valós működés modelljének elkészítésekor többkevesebb irracionalitással találkozunk. Esetleg van lehetőség arra, hogy az irracionalitások feltárásával lényegesen javítsuk az üzleti működést, ekkor beszélhetünk „business process re-engineering”-ről (BPR). Más esetben tudomásul kell vennünk, hogy a működés csak korlátozottan racionális, és csak a valóság modellezésére („business modelling, BM”) szorítkozhatunk. Az OVSZ esetében tradicionális okból elég heterogén szakmai gyakorlattal találkoztunk, ezért az alapvetően BM tevékenységnek tudatosan vállalt célja volt a szakmai gyakorlat egységesítésének támogatása. Akár BPR-ről, akár BM-ről van szó, az alábbi két alapvető módszer egyikét kell választanunk. (attribútumokkal) ruházhatók fel, amelyek az általánostól a speciális felé haladva öröklődnek. A tervezés során ez rengeteg munka megtakarítását teszi lehetővé. Ha például azt mondjuk, hogy a vérkészítmény egy objektum, s ennek egyik attribútuma a vércsoport, valamint azt mondjuk, hogy a vörösvérsejt koncentrátum egy fajta vérkészítmény, akkor már nem kell külön leírnunk, hogy a vörösvérsejt koncentrátum jellemzője a vércsoport. Folyamatorientált paradigma Az objektumorientált paradigma nagy előnye a flexibilitás. Példánknál maradva, ha bármikor szükség van arra, hogy egy új vérkészítményt vezessünk be a rendszerbe, elegendő meghatároznunk, hogy az új készítmény milyen speciális tulajdonságokkal rendelkezik. Ugyanez a logika nemcsak fizikai objektumokra, hanem műveletekre, (pl. készítmény-feldolgozás, laboratóriumi vizsgálat, szállítás, raktározás stb.) értelmezhető. A folyamatorientált megközelítés az intézményben zajló eseményeket folyamatba szervezve modellezi, (workflow elemzés) majd az események során keletkező illetve a döntési pontokon felhasznált adatokat trája föl. (Data flow). Ezek a folyamat-modellek képezik azután az informatikai rendszer tervezésének alapját. Az adatáramlási diagrammok alapján meghatározhatók az adatbázis-szerkezetek, az adatok közötti relációk, és az egyes műveleti pontok információigénye, ami majd adatmegjelenítési (pl. képernyő) tervekhez vezet. Az objektumorientált megközelítés előnye, hogy az üzleti modellezéstől a követelményspecifikáció elkészítésén és a rendszertervezésen át a programozásig módszertanilag teljesen koherens megoldást kínál. Az adatbázis és adatmegjelenítési tervek szinte automatikusan előállnak. Az objektumorientált tervezésben is megjelennek természetesen a folyamat-modellek, azonban a módszer hátránya, hogy a folyamatok tervezésének következetességét, optimalizálását nem garantálja. A folyamat-orientált megközelítés előnye, hogy segíti az üzleti folyamatok racionalizálását. Hátránya viszont, hogy az így létrehozott specifikáció viszonylag merev, nehezen követi az esetleges későbbi változásokat. Ennek megfelelően olyan esetekben javasolható, amikor viszonylag jelentős mértékű BPR tevékenységre van lehetőség illetve igény, viszont a kialakított üzleti folyamatok várhatóan hosszabb távon változatlanok maradnak, a környezeti feltételrendszer aránylag stabil. Tekintettel arra, hogy az OVSZ átalakulása, modernizációja nem lezárt történet, hanem az egész rendszer állandó mozgásban van, azt javasoljuk, hogy az OVSZ integrált informatikai rendszerének követelményspecifikációja objektumorientált megközelítésben készüljön. Az OVSZ-ben alkalmaztunk ilyen megközelítést, egy bizonyos vírusvizsgálati protokoll (az. ún anti-HbC vizsgálat) alkalmazásának gyakorlati szabályozására. Ennek során egymásnak részben ellentmondó szakmai megközelítéseket kellett összeegyeztetnünk, hogy egy kitisztázott és az informatikai rendszerben realizálható (leprogramozható) protokollhoz jussunk. Objektumorientált paradigma Az objektumorientált, megközelítésben az általános alapvázakat igyekszünk megragadni, minden konkrét tevékenységet, szereplőt, eszközt, dokumentumot valamilyen általános séma speciális eseteként fogunk fel. (Nem vállalkozhatunk az objektumorientált programozás és modellezés ismertetésére, csupán egy szemléletmódot próbálunk bemutatni, elnézést kérve a könnyebb megértés érdekében elkövetett pongyolaságokért.) Az objektumok tulajdonságokkal 28 IME I. ÉVFOLYAM 3. SZÁM 2002. OKTÓBER A követelményspecifikáció tartalma A folyamatorientált illetve objektumorientált paradigma közti választást már az üzleti modell készítésekor meg kell tenni. (Létezik olyan megközelítés is, ahol a folyamatorientált üzleti modellezést objektumorientált szoftver fejlesztés követi, ez azonban óhatatlanul felvet módszertani problémákat.). Az üzleti modell azonban csak kiinduló pontja a követelményspecifikációnak. Azt mondtuk, hogy az informatikai megoldás azt jelenti, hogy a rendszer minden szereplője a munkájához szükséges információt a megfelelő helyen, a megfelelő formában és a kellő időben megkapja. Az üzleti folyamatok feltérképezése után le kell írnunk azt a struktúrát, amelyben ezek a folyamatok zajlanak. (Ez is történhet úgy, hogy leírjuk a létező struktúrát vagy úgy, hogy a folyamatokból kiindulva levezetjük a működéshez szükséges struktúrát.) A struktúra és az üzleti folyamatok (mint két merőleges sík) egymásra vetítése fogja meghatározni az úgynevezett szolgáltatási pontokat: azokat a fizikai és szervezeti értelemben egyaránt létező helyeket, ahol az informatikai rendszernek valamilyen szolgáltatást kell nyújtania. Az adott szolgáltatási ponton nyújtandó informatikai szolgáltatás már INFOKOMMUNIKÁCIÓ FEJLESZTÉSI MÓDSZERTAN az üzleti folyamatból nagyon könnyen levezethető. Az OVSZ-ből vett példánál maradva: vérkészítmény felszabadításnak nevezzük azt a műveletet, ahol az elkészített és kivizsgált terméket gyógyászati felhasználásra alkalmasnak minősítik és ellátják az ehhez szükséges vonalkóddal és szemmel olvasható jelzésekkel. Ha az üzleti modellben már leírtuk, hogy ehhez a művelethez milyen objektumok milyen attribútumai tartoznak, akkor szinte automatikusan adódik, hogy a művelet kiszolgálásakor milyen input és output adatokra lesz szükség. Fontos, hogy a lehető legpontosabban meghatározzuk a rendszer mennyiségi jellemzőit (szolgáltatási pontok száma, tranzakciók gyakorisága, adatbázisok rekordszáma stb.), a teljesítményre (a rendszer gyorsaságára), flexibilitására és biztonsági szintjére (adatvédelem és rendelkezésre-állási biztonság) vonatkozó elvárásainkat. Feltétlenül meg kell adnunk azokat a környezeti elvárásokat (pl. alkalmazandó jogszabályok, szabványok), amelyeknek meg kell felelnünk. nyelv kétségtelen előnye, hogy mindenki tudja használni, nincs szükség semmilyen kifejező eszköz használatának hosszadalmas elsajátítására. Van két baj: a nyelv nem egyértelmű, semmilyen garancia nincs arra, hogy a szállító azt fogja megérteni belőle, amire mi gondoltunk. A másik, hogy egy terjedelmes – esetleg több száz oldalas – szöveges követelményspecifikáció esetében bajos az előző pontban felsorolt kérdésekre választ adnunk. Azt is tudnunk kell, hogy a követelmények sohasem változatlanok a projekt során. Ezeket a változásokat pontosan kell követni, hiszen épen ezek okozzák a legtöbb önellentmondást. Amikor ugyanis a követelmények egyik eleme megváltozik, egy szabad szöveges leírásban nem tudjuk annak minden összefüggését nyomon követni. Nagyobb projektek esetén ma már semmiképpen nem ajánlható, hogy a követelményspecifikáció egyszerűen szabad szöveges formában álljon elő, hanem többé-kevésbé strukturált formába kell tenni. CASE eszközök A JÓ KÖVETELMÉNYSPECIFIKÁCIÓ Mikor lehetünk elégedettek? Az alábbiakban egy nagyon tömör, amolyan check-list jellegű szempontrendszert adunk, amely segíthet eldönteni, hogy az elkészített követelményspecifikáció megfelelő-e. Ha ezekre a kérdésekre megnyugtató választ adhatunk, akkor sokat tettünk a projekt sikeréért. • • • • • • • • • Teljesség: Tartalmaz-e minden elvárást? Megoldás-függetlenség: Nem tartalmaz-e a megoldás módjára vonatkozó szükségtelen megszorítást? Túlspecifikáltság elkerülése: Nem tartalmaz-e szükségtelen megszorításokat? Egyértelműség: Következetes-e a szóhasználat, világosak-e az ábrák? Lefedés: Kiterjed-e minden támogatni kívánt folyamatra. Konzisztencia: Nem tartalmaz-e egymásnak ellentmondó követelményeket? Ellenőrizhetőség: Meg lehet-e győződni minden egyes követelménnyel kapcsolatban arról, hogy az adott követelmény teljesült-e? Flexibilitás: Kezelhetők-e a futamidő alatt várhatóan szükséges változások anélkül, hogy a követelményeket alapvetően meg kellene változtatni? Redundancia-mentesség: Nem szerepel-e többször ugyanaz az elvárás? A következő részben azt tekintjük át, hogy milyen technikákkal lehet ma egy követelményspecifikációt megjeleníteni. Szabad szöveges követelményspecifikáció Mi sem természetesebb, minthogy a követelményeinket egyszerűen leírjuk és átadjuk a szállítónak. A természetes CASE (Computer Aided Software Engineering) eszköznek nevezzük mindazokat a szoftvereket, amelyeket az informatikai rendszerek fejlesztésének támogatására hoztak létre, ide értve a fejlesztés teljes életciklusát a kiindulási helyzet felmérésétől a megvalósításig. Általában a CASE eszközök is folyamat- vagy objektumorientáltak lehetnek. Ezeket az eszközöket elsődlegesen a szoftver gyártók számára fejlesztették ki, ezért számos olyan szolgáltatásuk lehet, amelyek az intézmény számára szükségtelenek (pl. automatikus adatbázis vagy program-generálás). Ezeket a funkciókat azonban többnyire külön modulok valósítják meg, így nem kell a teljes funkcionalitást lefedő eszközrendszert megvásárolni. Az alábbiakban két olyan eljárást mutatunk be röviden, amelyekkel a követelményspecifikációt egzaktabbá és követhetőbbé tehetjük. Félig strukturált követelményspecifikáció Ennek a módszernek az alapgondolata, hogy a felhasználók számára mégiscsak legkönnyebb, ha szabad szövegben fejezhetik ki magukat. Az elvárásokat egy szövegdokumentumban rögzítjük, majd kijelöljük benne azokat a részeket, amelyek egy megfogható követelményt írnak le. A kijelölt részt egy adatbázis rekordjához kötjük. Ebben az adatbázisban azután az adott követelmény másokkal való összefüggéseit (dependencia mátrix), a követelmény típusát, megfogalmazóját stb. nyilvántarthatjuk, egyénileg megtervezett attribútumokkal láthatjuk el, és megvalósulását nyomon követhetjük a projekt egész folyamán. Ez a módszer a projekt menedzselését nagyon hatékonyan támogatja azáltal, hogy a követelményeket és a megvalósulásukat pontosan dokumentálja. Segít elkerülni a véget nem érő vitát arról, hogy a szállító teljesítette-e a követelményeket vagy sem. Önmagában alkalmazva azonban IME I. ÉVFOLYAM 3. SZÁM 2002. OKTÓBER 29 INFOKOMMUNIKÁCIÓ FEJLESZTÉSI MÓDSZERTAN nem alkalmas arra, hogy a követelményspecifikáció teljességéről vagy ellentmondás-mentességéről meggyőződjünk. Az UML alapú követelményspecifikáció Az UML (Unified Modelling Language) olyan grafikus rendszer-leíró nyelv, amelyet az objektum-orientált rendszerfejlesztés támogatására fejlesztettek ki [3]. Részletes ismertetésére nem vállalkozhatunk, az interneten számos információ található róla, sőt a teljes specifikációja publikus. (Lásd http://www.omg.org/uml). Ma már az UML használata kinőtte az eredeti kereteit. Egészségügyi informatikai szabványok, sőt orvosi szakmai protokollok leírásához is használják. Tökéletesen alkalmas objektum-orientált szemléletű üzleti modellezésre és követelményspecifikáció készítésére is. Az UML hét különböző diagram típust ismer, amelyek valamely rendszer hét különböző aspektusát képesek kezelni. Az üzleti modellezéshez és a követelményspecifikáció készítéséhez azonban általában nincs szükség mind a hét típusra. A három legfontosabb típus az ún. use-case, a folyamat, és az osztály diagram. A use-case diagram (használati esetnek szokták fordítani, szerencsésebb használati helyzetről beszélni, mert nem egyedi eseteket ír le) szolgál azoknak a típus-helyzeteknek a leírására, amelyben valamilyen külső szereplő a rendszert valamilyen céllal használja. Ha a „rendszer” nem az információrendszert, hanem pl. egy intézményt jelent, akkor máris nyitva az út az UML alapú üzleti modellezés előtt. A folyamat diagram azt mutatja meg, hogy az adott cél milyen algoritmus szerint valósul meg, az osztály-diagram pedig a folyamat során felhasznált, keletkező vagy abban résztvevő objektumokat és azok kapcsolat-rendszerét írja le. Ha annyit sikerül elérnünk, hogy minden szituációt le tudunk írni, amikor valamely külső szereplő meghatározott céllal igénybe veszi a rendszert, akkor módszeresen végighaladva nagy valószínűséggel minden belső szereplőt, folyamatot le fogunk tudni képezni, kivéve azokat, amelyeknek soha semmilyen szereplővel áttételesen sincs kapcsolatuk. A módszer alkalmazása az üzleti modellezésben többek közt épp ezért csábító, nemcsak a valóságot képezi le, hanem eleve kihagyja a létező de szükségtelen elemeket. Természetesen az UML-nek is vannak nyelvi korlátai, nem ritkán szükség lehet pl. az UML-ben leírt követelmények természetes nyelvi kiegészítésére. Ilyen esetben is sokat segít azonban a követelmény-specifikáció teljessé és következetessé tételében. Az UML óriási előnye, hogy grafikus megjelenése folytán a felhasználó számára igen rövid magyarázat után felfogható, vizuálissá teszi a majdani rendszer működési logikáját, amely egyébként csak nagyon elvont módon magyarázható. Ennek érzékeltetésére bemutatunk egy kísérletképpen készített diagrammot. 30 IME I. ÉVFOLYAM 3. SZÁM 2002. OKTÓBER 1. ábra A vérkészítmény-feldolgozás elemi lépésének általános sémája Az 1. ábra a készítmény-feldolgozás általános sémáját mutatja be. Arról szól, hogy minden valóságos konkrét feldolgozási lépés (az ábra közepén látható téglalap jelöli) egy vagy több prekurzorból egy vagy több produktumot állít elő, a műveletet mindig valamely felelős személy (operátor) végzi, valamely eszköz segítéségével és valamilyen anyag fölhasználásával. Minden ilyen elemnek meghatározott attribútumai vannak. A művelet során a produktum attribútumait a középső téglalap alsó szeletében feltüntetett függvények generálják a többi objektum attribútumai alapján. Pl. ha a prekurzort már egy adott beteg számára lefoglalták (ezt a „foglalt” attribútum jelöli), akkor ennek a produktumra is át kell öröklődnie, amiről a foglaltság.gen() függvénynek kell gondoskodnia. Az ábrán az egyszerű nyilak az objektumok kapcsolódásait jelzik, a háromszögfejű nyilak a speciális-általános relációt mutatják. A feldolgozás mint művelet (<
>) a termelési műveletek speciális esete. Minden termelési műveletnek van inputja és outputja, ezek speciális esetei a prekurzor és a produktum. INFOKOMMUNIKÁCIÓ FEJLESZTÉSI MÓDSZERTAN Az általános modellből nagyon könnyen le lehet vezetni az konkrét feldolgozási lépések leírását. Ugyancsak könnyen levezethető az az adtabázis modell, amely minden elképzelhető feldolgozási műveletre vonatkozóan tárolja az itt megjelenő objektumok attribútum értékeit. Ha egy informatikai rendszer képes egy ilyen általános modellt kezelni (ezt az objektum orientált programozási technika garantálja) akkor abban bármikor nagyon könnyen lehet újabb, addig nem ismert feldolgozási műveletek informatikai támogatását realizálni. ZÁRSZÓ A követelményspecifikáció fontosságát hangsúlyozó érveinket nem szeretnénk megismételni. Azt sem állítjuk, hogy a követelményspecifikáció készítésének minden aspektusát megvilágítottuk. Célunk csupán annyi volt, hogy próbáljuk érzékeltetni: az informatikai fejlesztésekkel kapcsolatos szkepszis nem alaptalan ugyan, de a kudarcnak majdnem mindig előre látható okai vannak, és léteznek megoldások, módszerek a kudarc kockázatának csökkentésére. Ennek egy szűk szeletét mutattuk be ebben az írásban. IRODALOMJEGYZÉK [1] Farkas A., Kiss L.: Az SSADM (strukturált rendszerelemzési és -tervezési módszer) ismertetése KFKI 1988., Budapest [2] Raffai Mária: Egységesített megoldások az alkalmazásfejlesztésben, Novadat, 2001., Budapest [3] James Rumbaugh, Ivar Jacobson, Grady Booch: The unified modeling language reference manual AddisonWesley 1999., Reading, Massachusetts A SZERZÔK BEMUTATÁSA Dr. Surján György orvos informatikus. Egyetemi diplomáját 1983-ban szerezte a Semmelweis Orvostudományi Egyetem általános orvosi szakán. 1983-tól tíz éven át fül-orr-gégészként dolgozott, majd 1993-től a klinikai tevékenység mellett a Haynal Imre Egészségtudományi Egyetem Adatszolgáltatási Osztályát vezette. 2000-től az Országos Vérellátó Szolgálat informati- kai főigazgató-helyettese. A Neumann János Számítógéptudományi Társaság Orvos-biológiai Szakosztályának titkára, a MEIT vezetőségi tagja. 1993-óta az Európai Szabványosítási Bizottság Egészségügyi Informatikai Műszaki Bizottságába delegált magyarországi megfigyelő. Részt vett európai szabványosítási projektben. A Veszprémi Egyetemen oktat, rendszeres felkért előadó a Semmelweis Egyetemen. Fő kutatási területe a számítógépes orvosi ismeretreprezentáció. Dr. Szabó János Elemér orvos, hematológus és transzfuziológus szakorvos. Diplomáját a Semmelweis Orvostudományi Egyetem, általános Orvosi Karán szerezte, 1971-ben. A diploma megszerzése óta gyakorlatilag az Országos Vérellátó Szolgálat illetve az Országos Hematológiai Intézet jogelőd intézményeiben dolgozott. 1980-ban hematologiai 1995-ben transz- fúziologiai szakvizsgát tett. 1991-96 között főigazgató-helyettes, (OHVII), 1996-98 között főigazgató, (OVK - OVSZ) 1999-óta főigazgató helyettesként, ill. tudományos tanácsadóként dolgozik az OVSZ-ben. Tagja az Európa Tanács Transzfúziós Szakértői Bizottságának. Fontosabb szakterülete a vérellátás szervezeti korszerűsítése, a minőségügyi rendszer kialakítása, a ”PELIKáN” vérellátási szoftver (készítő: Dynasoft Kft.) követelményspecifikáció szakmai irányítása, készítése, betanítás koordinálása. IME I. ÉVFOLYAM 3. SZÁM 2002. OKTÓBER 31 