Informatika | Gazdasági Informatika » Frank Péter - Üzleti intelligenciát támogató alkalmazások kialakítása

HALLGATÓI NYILATKOZAT Alulírott Frank Péter, szigorló hallgató kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat (szakirodalom, eszközök, stb.) használtam fel Minden olyan részt, melyet szó szerint, vagy azonos értelemben de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem. Tudomásul veszem, hogy az elkészült diplomatervben található eredményeket a Budapesti Műszaki és Gazdaságtudományi Egyetem, a feladatot kiíró egyetemi intézmény saját céljaira felhasználhatja. Kelt: Budapest, 2009. 05 14 . Frank Péter Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Automatizálási és Alkalmazott Informatikai Tanszék F RANK P ÉTER ÜZLETI INTELLIGENCIÁT TÁMOGATÓ ALKALMAZÁSOK KIALAKÍTÁSA KONZULENSEK OLÁH ISTVÁN – BME AAIT GARAMI GÁBOR – E-GROUP BUDAPEST 2009 Kivonat A modern

társadalmakban tapasztalható teljesítményközpontúság szülte elvárások túllépték a múlt századi, szigetmegoldásokra épülő informatikai infrastruktúra korlátait. A szervezeteknek olyan eszközökre van szükségük, melyek az üzleti folyamatok menedzselésével és nyomon követésével szilárdítják meg piaci pozícióikat. A dolgozat célja áttekinteni, hogy az ipari szereplők számára milyen, az alkalmazások interoperabilitását kihasználó eljárások állnak rendelkezésre termelékenységük és hatékonyságuk növelése érdekében. A problémakör mind szoftveripari, mint általános vonatkozásban bemutatásra kerül. A diplomatervben leírtak alátámasztására elkészült egy általános célú, csoportmunkát, munkafolyamatokat és üzleti intelligenciát támogató informatikai rendszer. A megoldás egy kérvényezési és riportkészítési folyamatot valósít meg, mely a Microsoft Corporation Office SharePoint Server 2007 és Windows

Workflow Foundation technológiáit alkalmazva szemlélteti a szoftverek együttműködéséből származó előnyöket. Abstract The performance-centric expectations noticed in modern societies are far beyond the isolated solutions provided by the twentieth century IT infrastructure. Companies are in need for advanced tools to consolidate their positions on the global market by tracing and managing the business processes. The main scope of this thesis is to review methods which take advantage of the interoperability between applications to enhance efficiency and productivity of organizations. The issue is analyzed in relation to both software industrial and general cases. In support of the theory an IT system was constructed providing groupware, workflow and business intelligence functionality. The purpose of the solution is to demonstrate the benefits of cooperation between applications by realizing a petition-reconsideration and reporting process using Microsoft Corporation’s

Office SharePoint Server 2007 and Windows Workflow Foundation technologies. Tartalomjegyzék 1. BEVEZETÉS 1 2. CSOPORTMUNKA RENDSZEREK 3 2.1 A csoportmunka rendszer meghatározása 3 2.11 Munkacsoportok 3 2.12 A munkacsoport jellemzői – a három „C” 4 2.2 A csoportmunka rendszer követelményei 8 3. SZOFTVERFEJLESZTÉS NAGYVÁLLALATI KÖRNYEZETBEN 9 3.1 CMMI 9 3.11 Folyamatos modellértelmezés 10 3.12 Lépcsőzetes modellértelmezés 11 3.2 Szoftver-életciklus modellek 14 3.21 Vízesés (Waterfall) modell 14 3.22 Iteratív inkrementális modell 15 3.23 Spirál modell 15 3.3 Agilis szoftverfejlesztési módszertanok 17 3.31 Az agilis módszertanok alapelvei 18 3.32 Összehasonlítás a hagyományos módszertanokkal 18 3.33 Scrum 19 3.4 MSF – Microsoft Solutions Framework 22 3.41 Az MSF alapelvei 22 3.42 Az MSF csapat – és folyamatmodellje 23 4. MICROSOFT CSOPORTMUNKA MEGOLDÁSOK 28 4.1 Team Foundation Server 28 4.11 Projektmenedzsment 28 4.12

Portál 29 4.13 Munkaelem-követés 29 4.14 Változáskövetés 30 4.15 Fordítókiszolgáló 31 4.16 Jelentések 31 4.2 SharePoint Server 2007 32 4.21 Az igény kialakulása 32 4.22 A SharePoint szolgáltatásai 33 4.23 A SharePoint üzleti intelligencia megoldásai 38 4.3 NET Workflow Foundation 46 4.31 A Workflow Foundation szolgáltatásai 46 4.32 A Workflow Foundation folyamatai 50 4.33 A Windows Workflow Foundation és a SharePoint Server 2007 52 4.34 A Workflow Foundation összefoglalása 52 5. ÜZLETI INTELLIGENCIÁT TÁMOGATÓ RENDSZER KIALAKÍTÁSA 53 5.1 Feladatspecifikáció, követelmények megfogalmazása 53 5.11 A feladat leírása 54 5.12 A követelmények megfogalmazása, specifikáció 54 5.2 Az architektúra tervezése 60 5.21 A platform kiválasztása 60 5.22 A felhasznált technológiák meghatározása 61 5.23 A rendszer architektúrája 64 5.3 A rendszer megvalósítása 67 5.31 A szerepkörök definiálása, jogosultságok

meghatározása 67 5.32 Kérvény – és feladattárak létrehozása 68 5.33 A kérvény-elbírálási folyamat megvalósítása 74 5.34 Az üzleti intelligencia megvalósítása 78 5.35 A rendszer értékelése 86 6. ÖSSZEFOGLALÁS 90 KÖSZÖNETNYILVÁNÍTÁS . 92 MELLÉKLET TARTALMA. 93 IRODALOMJEGYZÉK . 94 FÜGGELÉK . 95 Ábrajegyzék 1. ábra Csoportmunka támogató infrastruktúra 4 2. ábra Az együttműködés eszközei 5 3. ábra Folyamatos modellértelmezés 10 4. ábra Képességi szintek 11 5. ábra Lépcsőzetes modellértelmezés 12 6. ábra Vízesés modell 14 7. ábra Spirál modell 16 8. ábra Módszertanok összehasonlítása 18 9. ábra MSF Csapatmodell 24 10. ábra MSF Folyamatmodell 26 11. ábra SharePoint Server 2007 33 12. ábra Az Excel Services felépítése 40 13. ábra KPI lista példa 43 14. ábra SharePoint Dashboard minta 44 15. ábra A WF elhelyezkedése a Windows platformon 47 16. ábra Visual Studio 2008 Workflow Designer

működés közben 49 17. ábra Kérvény-jóváhagyási folyamat 57 18. ábra Riportgeneráló folyamatok 58 19. ábra A megvalósítandó rendszer-architektúra 64 20. ábra SharePoint adminisztrátor beállítása 67 21. ábra A szerepkörök jogosultságai 68 22. ábra Kérvényeket tartalmazó dokumentumtár létrehozása 69 23. ábra A kérvények dokumentumtára 70 24. ábra A feladatok listája 72 25. ábra A tartalomindexelés beállítása 73 26. ábra Workflow hozzárendelése dokumentum - és feladattárhoz 75 27. ábra A kérvényt elbíráló felület 76 28. ábra Automatizált folyamatokat vezérlő felület 78 29. ábra Az aggregációs adatbázis 80 30. ábra Biztonságos adatkapcsolat megkövetelése 80 31. ábra KPI lista beállítása 82 32. ábra A kérvényezőrndszer riportfelülete 83 33. ábra A jelentést tartalmazó e-mail üzenet 85 1. Bevezetés A XXI. század hajnalán az informatikai eszközök meghatározzák a fejlett

országokban élő emberek mindennapjait. Az Internet népszerűségének köszönhetően egyre többen élnek az elektronikus ügyintézés nyújtotta kényelmi szolgáltatásokkal, tervezik meg utazásaikat online térképadatbázisok segítségével vagy tartják kapcsolatot távol élő rokonaikkal. A mobiltelefonok tulajdonosai bárhol és bármikor elérhetik egymást, s a modern készülékeknek hála, felcsatlakozhatnak a világhálóra. Az említett megoldások önmagukban is rendkívül sokoldalúvá teszik az informatika felhasználását, de összekapcsolásukkal további távlatok nyílnak meg az alkalmazott számítástechnikában. A multinacionális szervezetek felismerték, hogy piaci pozícióikat csak úgy képesek megtartani, ha konkurenseikkel együttműködve az interoperabilitás szellemében készítik termékeiket. A közös munkával kialakított, jól definiált interfészek előnyeinek haszonélvezői a felhasználók, akik hardver – és

szoftvereszközeikkel korábban elképzelhetetlennek hitt szolgáltatásokat vehetek igénybe. Mindezek ellenére az informatikai fejlődéssel szemben szkeptikus vagy számítástechnikai szakértelemmel nem rendelkező szervezetek gyakran szembesülnek a ténnyel, hogy az ügyfeleikkel való kapcsolattartás során felhalmozódó információmennyiség feldolgozása és rendszerezése rengeteg adminisztratív munkával jár. A komplex projektek sikeres megvalósítása globalizált környezetben, analóg módon, kizárólag emberi erőforrások bevonásával nem lehetséges. A versenytársakkal szembeni helytállás alapfeltétele, hogy a cég teljesítménye numerikus értékekkel kifejezhető, s ez alapján növelhető legyen, melyre szintén a szoftveripar biztosít módszereket. Az említett tulajdonságokkal és hiányosságokkal rendelkező vállalatok számára jelentenek megoldást a csoportmunka rendszerek, melyek az informatikai eszközök összekapcsolásával az

emberi kommunikációt és együttműködést egy magasabb szintre emelik. A csapatmunkát tudatosan alkalmazó szervezetek hatékonyságának alapja, hogy a cég tetszőleges alkalmazottja bármilyen körülmények között kapcsolatba tudjon lépni másokkal. Az egyének tevékenységét hosszú lefutású, komplex munkafolyamatok hangolják össze, melyek biztosítják az ügymenet mindenkori pozitív végkimenetelét. A koordinációs mechanizmusnak köszönhetően minimalizálhatóak a személyiségek sokféleségéből adódó konfliktusok, mert az elvégzett/elvégzetlen feladatok pontosan nyomon követhetők. A vállalatok vezetői szintén profitálnak a heterogén technológiák együttműködéséből, mert az egyre nagyobb népszerűségnek örvendő BI1 megoldások tárháza áll rendelkezésükre riportok, jelentések és prognózisok elkészítésében. 1 Business Intelligence, magyarul: üzleti intelligencia 1 A diploma dolgozat célja, hogy áttekintse,

majd egy mintamegoldáson keresztül bemutassa a szoftverfejlesztés és egyéb szakterületek esetén sikeresen alkalmazható csoportmunkát, munkafolyamatokat és üzleti intelligenciát támogató informatikai rendszereket. A második fejezet általánosan ismerteti a munkacsoportok fogalmát és az őket támogató informatikai infrastruktúra követelményeit. Ezt követően a harmadik szakasz bemutatja a szoftverfejlesztésben kiemelkedő fontosságú csapat – és folyamatszemlélet alapját képező alkalmazásfejlesztési metodológiákat, ajánlásokat. A megelőző témakörökben tárgyaltakra mutat iparban is alkalmazott megoldásokat a negyedik passzus, mely részletezi a Microsoft Corporation rendszerfejlesztésre optimalizált és független felhasználású csoportmunkát, munkafolyamatokat és üzleti intelligenciát támogató technológiáit. Végül az ötödik fejezet a leírtak gyakorlatba ültetéséhez egy kérvény-elbírálást és riportkészítést

megvalósító rendszer elkészítésének és vizsgálatának lépéseit ismerteti, melynek futtatását és tesztelését a VMware, Inc virtualizációs eljárása tette lehetővé. 2 2. Csoportmunka rendszerek A cégek, szervezetek növekedésének természetes velejárója, hogy működésükben és az ezzel járó feladatok végrehajtásában egyre több ember vesz részt. Az ügyek intézése során folyamatos formális és informális információcsere zajlik a résztvevők között, s mire az ügy lezárul, sokszor jóval többen foglalkoztak az adott aktával, megrendeléssel, megbízással, mint valójában kellett volna. Amíg az iratok kézzel vagy írógéppel készültek, illetve kerültek sokszorosításra, korlátozni lehetett az ügyintézés, mint adatfeldolgozó rendszer bemenetét. A személyi számítógépek elterjedésével (1980-1985) minden munkahelyen megjelentek az irodai munkát segítő szoftverek (szövegszerkesztők, táblázatkezelők,

tervezőprogramok), melyek jelentős mértékben növelték a produktivitást. A megnövekedett termelékenység folytán létrejött papírmennyiség egy idő után rendkívüli módon belassította az ügymenetet. A számítógépek hálózatba kapcsolásával nyílt lehetőség olyan programrendszerek létrehozására, melyek már nem csak az egyén, hanem több ember munkájának hatékonyságát is növelték. Az Internet és intranet kiterjedése az akadémiai, katonai szférán kívülre a közigazgatásban és az üzleti életben tovább szélesítette az alapokat, növelte a dolgozók együttműködési lehetőségeit. [1], [2] 2.1 A csoportmunka rendszer meghatározása A „csoportmunkát támogató információs rendszer” (angolul groupware) kifejezésen azon szoftver eszközök összefoglaló nevét értjük, amelyeket munkacsoportok, illetve teamek együttes munkájának támogatására, hatékonyságának fokozására terveztek. Ezek az eszközök ugyanolyan módon

segítik a csoport munkáját, mint a hagyományos programok az egyének tevékenységét. 2.11 Munkacsoportok Az informatikai eszközök használatának elterjedése a legtöbb vállalatban szervezetátalakításokat indukált. A trendek egyértelműen a termelékenység növelésének irányába mutatnak, minél kevesebb emberrel kell jobb eredményeket elérni. Más tényezők, mint például a megnövekedett minőségi elvárások, jobb vevőszolgálat, alacsonyabb eladási költségek, nagyobb alkalmazotti autonómia és rugalmas, fogékony szervezet iránti igény jellemzi a jelenlegi helyzetet. A megváltozott szervezeti rendszerben, bármilyen jellegű is volt korábban a cég felépítése, egyes feladatok megoldásánál előtérbe kerül a projekt szemlélet. Jelentősek azok a heterogén vállalati csoportok, melyek nem tartoznak bele a funkcionális szervezeti keretekbe. 3 Ezek a csoportok felelősek egy-egy üzleti folyamatért vagy projektért. A groupware az

információtechnológia olyan alkalmazása, mely kiterjeszti eme csoportok lehetőségeit. Munkacsoportokat minden szervezetben találunk, formálisakat és szervezeti keretbe be nem illeszthetőeket egyaránt. Fontos megérteni, hogy a groupware nem egy újabb állomása a szoftverek fejlődésének. Sokkal inkább úgy kell rá tekinteni, hogy olyan alkalmazásokról van szó, melyek támogatják a szervezet „természetes” struktúráját. Ezért nem is mindig az a cél, hogy egy új struktúra jöjjön létre, amit munkacsoportnak hívunk, hanem sokkal inkább a meglévő csoportok hatékonyságát és hatásosságát kell javítani. 2.12 A munkacsoport jellemzői – a három „C” A szervezeten belüli csoportok produktivitásának növelése érdekében meg kell érteni a munkacsoportok három alapvető tulajdonságát: a kommunikációt, együttműködést és a koordinációt (communication, collaboration, coordination – three C’s). 1. ábra Csoportmunka támogató

infrastruktúra A három tényezőt a klasszikus szoftverek tradicionálisan különálló termékként és szolgáltatásként támogatták. A legtöbb felhasználó tapasztalata csak a groupware egy‐egy részterületére terjedt ki, ezért az elektronikus posta – e‐mail – felhasználói természetesen az elektronikus üzenetkezelés szemüvegén keresztül látják azt. Az elektronikus űrlapokat áramoltató termékek alkalmazói úgy tekintettek a csoportmunka rendszerre, mint az ügymenetkezelés (workflow automation) egy funkciója. Az elektronikus konferencia rendszerek vagy a WWW (World Wide Web) felhasználói az információhoz történő közös hozzáférést gondolják a groupware alapjának. Egy csoportmunka rendszer hatékony megvalósításánál mindhárom tényezőnek jelen kell lennie. Nem definiálható egyszerű technológiaként, vagy alkalmazások gyűjteményeként, ugyanis a három jellemző a rendszerek egymástól való függőségére épít. Az

együttműködő 4 felek földrajzi (azonos vagy eltérő hely), illetve időbeli (azonos vagy eltérő idő) elhelyezkedésétől függően a groupware az alábbi technológiákat alkalmazhatja. A megnevezések egyes esetekben kielégítő minőségű magyar megfelelő hiányában eredeti nyelven szerepelnek: Eltérő hely és idő fax e-mail voice-mail video-mail Kommunikáció     Együttműködés  dokumentum megosztás Koordináció Eltérő hely, azonos idő telefon audió rendszerek videó rendszerek chat rendszerek (Skype, MSN)  whiteboard  shared CAD  megosztott virtuális tábla      csoportnaptár  üzenőfal  megosztott  feladat ütemező rendszer folyamatirányító  értesítő rendszer rendszer  eseménykezelő rendszer 2. ábra Az együttműködés eszközei Azonos hely és idő  chat rendszerek  belső kommunikációs rendszer  csoportos döntéstámogató rendszer  irányító központ 

feladatkiosztó rendszer  Kommunikáció A csoportmunka rendszerek leginkább alulértékelt problémája a kommunikáció. A legtöbb szervezet jelentős összegeket fordít arra, hogy kiépítse a telefonos és számítógép alapú kapcsolattartást. Fontos szem előtt tartani, hogy a fejlesztésekbe invesztált tőke nagysága nem egyenesen arányos az így kialakuló kommunikációs infrastruktúra minőségével. A groupware rendszerek bevezetésénél meg kell határozni azokat a kritikus csatornákat, melyek hozzátartoznak az alapműködéshez, és az egyes munkacsoportokat arra ösztökélni, hogy teljes mértékben használják ki a technikai háttér nyújtotta lehetőségeket. A kommunikációs rendszer két alappillére a megbízhatóság és az elérhetőség. Mivel a szervezetek minden folyamatot és munkát számítógép alapú környezetben végeznek el, a kapcsolattartásért felelős informatikai infrastruktúra tekinthető azok „idegrendszerének”. A

megbízhatóság biztosítható megelőzéssel, illetve utólagos reagálással. Előbbi megoldás jóval robosztusabb megoldást kíván. Ez a módszer folyamatosan vizsgálja a rendszert, hogy kellőképpen megbízható legyen, és statisztikai modelleket használ a megelőző karbantartás ütemezésére. Az utólagos reagálás, mely jóval inkább elterjedt, azon alapul, hogy meghatározzák az egyes funkciókra bontva a leállás maximális idejét és kialakítják azokat az eszközöket és eljárásokat, melyek lehetővé teszik, hogy ezen időszak alatt a hibát ki lehessen javítani. 5 A szervezetek és csoportok a kommunikáció sokféle formáját használják, ezért fontos, hogy ezek közül mindegyik integrálva legyen a csoportmunka rendszerbe, ezzel bármikor elérhetőek lesznek az egyének és erőforrások, mely elengedhetetlen a tevékenység sikeres végrehajtásához. Az információs technológiák konvergenciája révén a létező kapcsolattartási

lehetőségek átlendülhetnek eddigi lehetőségeink határán. A csoportmunkát támogató rendszernek bővíthetőnek kell lennie, hogy befogadja és alkalmazni tudja az olyan, főleg mobilitás nyújtotta újításokat, mint az e-mailek elolvasása a mobilkészüléken, illetve az adat hang és videó egyazon fizikai közegen keresztül történő átvitele.  Együttműködés Az együttműködés a groupware „agya”, mely lehetővé teszi, hogy a szervezet az intellektuális erőforrásokra koncentráljon. A számítógéppel támogatott kooperáció fő előnye, hogy feloldja az időbeli és területi korlátokat, így eltérő helyen és időzónában élő emberek lehetnek tagjai ugyanannak a munkacsoportnak. Az értekezlet, mint a csoportmunka fő fóruma veszít jelentőségéből, hiszen a groupware termékek használói folyamatosan megoszthatják tapasztalataikat függetlenül földrajzi elhelyezkedésüktől. A hagyományos meetingek a frissen felmerült

problémák ad-hoc megoldását szolgálják, ezért nincsenek megfelelően strukturálva, s az értékes tudás, illetve az együttműködésből leszűrhető tapasztalat csak egyszer szolgálja a cég érdekeit, utána elveszik. A csoportmunka rendszerek ezzel szemben a megszületett eredményeket tárolják, kategorizálják, s bárki számára elérhető helytől és időzónától függetlenül. A legtöbb szervezetnél a kommunikáció fő eszköze az intranetes levelezés. Az e-mailen keresztül történő kooperáció kisebb feladatok és rövid folyamatok esetén működőképes, azonban hosszútávon komplex és bonyolult problémák megoldásakor használhatatlanná válik. Ennek oka, hogy nehézkes a téma szerinti keresés, és a beszélgetések fonalának nyomon követése szinte lehetetlen, nem tudni, hogy ki kinek válaszol és milyen sorrendben. A csoportmunka rendszerekben használatos osztott adatbázisok virtuális munkahelyet teremtenek, olyan csoport központú

interfésszel, mely a résztvevőknek lehetővé teszi az ötletek és információk megosztását. Az osztott adatbázis technológia az úgynevezett „szívásos” (pull) modellt alkalmazza, mely lehetővé teszi a felhasználó számára, hogy csak azokat az információkat kapja meg, amikre szüksége van. A résztvevőknek lehetőségük van arra, hogy az adatokat saját igényeik szerint jelenítsék meg, illetve hogy dokumentum-csatolmányokkal, illetve jellemzőkkel lássák el az egyes bejegyzéseket. Az osztott adatbázisok az információ kezelését a felhasználóra bízzák, ezért természetüknél fogva passzívak. Az együttműködési folyamat gördülékeny és gyors működése 6 érdekében mindig szükség van egy olyan alrendszerre, mely az egyes résztvevőket időről időre tájékoztatja az adatok megváltozásáról és a folyamatok állapotáról.  Koordináció A koordináció az a tényező, mely szinkronizálja a csoport erőfeszítéseit,

biztosítja az erőforrások és eredmények megosztását, illetve az üzleti folyamat lehető leghatékonyabb végrehajtását. A számítógépes támogatottság nélküli munkacsoportokban a koordináció korábban lefektetett szabályok által biztosított, megállapodásokon alapuló módszereken alapszik. Hátrányai a következők:  a munka előrehaladása kizárólag időszakosan ellenőrizhető  feltételezi, hogy minden, a munkafolyamatra hatással lévő tényező már a tervezési fázisban azonosítható és beépíthető a tervbe  a folyamat előrehaladását nem képes önmagában mérni, csak a tervhez viszonyított eltéréseket észleli  a vezetők kizárólag összegzett információk alapján döntenek, nem veszik figyelembe a sokszor jelentős részleteket, mivel nincsenek olyan eszközeik, melyek fel tudják dolgozni a nagy tömegű információt Azoknál a cégeknél, melyek gyorsan változó környezetben működnek, elengedhetetlen

számítógépes támogatottságú munkacsoport-koordináció. Az informatikai eszközökkel megvalósított, a részletekre is intenzíven figyelő automatizmus lehetővé teszi a folyamatok részletesebb nyomkövetését. Az előző pontokban vizsgált üzenetkezelést és együttműködést az információ megosztásának strukturálatlan mivolta jellemzi, mivel a tevékenységek szükségleti alapon zajlanak. Ezzel szemben az üzleti folyamatok jelentős része sokkal inkább strukturált természetű. Az írásban lefektetett, vagy szokásjogon alapuló szabályzatok meghatározzák, hogy az egyes dokumentumoknak milyen hivatali utat kell bejárniuk, hogy a folyamat követhető, végrehajtható és biztonságos legyen. Az egyes feladatok meghatározott sorrendben, időre történő elkészülése érdekében koordinálni kell az érintetteket, mely a rendszer szempontjából aktivitást igénylő tevékenység. Az ügymenet áramoltatása többnyire különféle űrlapok

(formok) segítségével történik. Használatukhoz egyértelművé kell tenni, hogy a külső adatokhoz hogyan lehet hozzáférni, módosítani, ismerni kell az elágazások választási feltételeit, stb. Mindehhez szükség van egy olyan alkalmazás fejlesztő rendszerre, mellyel ezeket a feladatokat meg lehet oldani. Természetesen a koordináció nem merül ki a strukturált adatok áramoltatásában. A folyamat szempontjából külső résztvevőkkel való kapcsolattartás miatt a koordinációs mechanizmusnak 7 támogatnia kell az informális csatornákat, mely a felhasználó számára lehetővé teszi az információk beszerzését. 2.2 A csoportmunka rendszer követelményei A groupware rendszerek célja az, hogy hatékonyabbá, gördülékenyebbé tegyék a szervezetek munkáját. Ahhoz, hogy ez teljesüljön, az alábbi követelményeket teljesíteniük kell:  a kommunikációs és üzenetkezelő infrastruktúrának teljesnek és megbízhatónak kell lennie,

támogatnia kell a felhasználók közötti információ-megosztást földrajzilag távol eső helyszínek esetén is  a csoportoknak képesnek kell lennie a létező kommunikációs infrastruktúra bővítésére  a csoporttagok által igényelt együttműködési formák technikai támogatását kell megvalósítani  lehetővé kell tenni, hogy a munkacsoportok kontrollálhassák a koordinációs mechanizmusukat  támogatniuk kell az üzleti folyamatok automatizálását  alkalmasnak kell lenniük dokumentumok tárolására, visszakeresésére, dokumentumokban való keresésre, a hozzáférés szabályozására  magas szintű biztonsági védelemmel kell rendelkezniük  hatékony és könnyen programozható fejlesztői környezetet kell nyújtaniuk A csoportmunka rendszerek alkalmazásának elsődleges indoka a versenyképesség növelése olyan szoftver eszközök segítségével, melyek elősegítik az üzleti folyamatok akadálytalan

lefolyását és növelik a szervezet produktivitását. A fenti követelmények teljesülése nem csak az aktuális teljesítményre van jótékony hatással, de képessé teszi a cég vezetőit olyan döntések meghozatalára, amikkel erősíthetik a szervezet piaci pozícióját. Az informatikai eszközökkel segített közös munka eredményeképpen rövidebb idő alatt lehet magasabb színvonalú, valódi értékeket teremteni. 8 3. Szoftverfejlesztés nagyvállalati környezetben Az 1960-as évek végén – a szoftverfejlesztés hajnalán – mielőtt a programozás önálló szakmává vált volna, a fejlesztők számára az egyénileg kidolgozott technikák követése volt az egyetlen lehetőség, hogy munkájukat valamiféle rendszerben végezzék el. A csoportmunka kialakítása esélytelen volt, mert az elkészült programkód logikáját gyakran csak az alkotója volt képes értelmezni. A szoftverek összetettebbé válása ráébresztette a fejlesztőket, hogy

komplex rendszereket nem lehet egyedül kézben tartani, ezért csapatokban kezdtek dolgozni. A csoportmunka térnyerésével elindult egy folyamat a szoftverfejlesztés technikájának elvi alapokon történő megfogalmazása felé. Bizonyos módszerek nagyon sikeresnek bizonyultak, amely újabb szabályozások kialakítására ösztönözte a szakterület képviselőit. Az elmúlt évtizedekben számos szabályrendszer vált elfogadottá, melyek között fellelhetőek az egy-egy szervezet által menedzselt komplex módszertanok is. A XXI. századi szoftveripar professzionális termékeket gyártó cégeinek szervezeti struktúrája jogosan érdemelheti ki a komplex jelzőt. A világszínvonalú alkalmazások létrejöttének a fejlesztők és tesztelők mellett egyaránt aktív résztvevői a projekt menedzserek, üzleti elemzők, architektek, üzemeltetők és egyéb egyedi szerepkörökben dolgozó szakemberek. A különböző képesítésű és eltérő érdeklődésű munkaerő

összefogása és hatékony együttműködése érdekében a szervezetnek alkalmaznia kell olyan standardokat és modelleket, melyek a cégfilozófia gyakorlati megvalósulását segítik elő. Az ajánlások között megtalálhatóak folyamatszervezési és szoftverfejlesztési módszertanok (CMMI, MSF, Scrum, stb.), illetve szoftver-életciklus modellek (Vízesés, Iteratív, Spirál, stb.) melyek a következőkben kerülnek bemutatásra. 3.1 CMMI A CMMI2 egy termék teljes életciklusára vonatkozó gyakorlatokat és praktikákat tartalmazó folyamatfejlesztési referencia modell. Első változatát a SEI3 fejlesztette ki a szoftverfejlesztési folyamatok szervezettségének meghatározására. 1990-es bemutatkozása után további modelleket dolgoztak ki egyéb szakterületek eljárásaira is, mint például a rendszertervezés, erőforrás-kezelés, rendszerintegráció. Cél a műveletek hatékonyságának és a végrehajtás teljesítményének növelése, a végrehajtás

költségeinek csökkentése, a végtermék minőségének magas szinten tartása a szervezeti fejlettség folyamatos monitorozásával 2 Capability Maturity Model Integration 3 Software Engineering Institute 9 párhuzamosan. A CMMI filozófiája jól definiálható a folyamatfejlesztés alaptételével: „A termék minőségét az őt létrehozó és karbantartó folyamat minősége határozza meg”. A CMMI kétféle reprezentációt biztosít a modellek értelmezéséhez: folyamatos (continuous) és lépcsős (staged). Tartalma mindkettőnek ugyanaz, csak az értelmezés különbözik, más-más szempontokat helyeznek előtérbe. [3] 3.11 Folyamatos modellértelmezés Az egyes folyamatok fejlesztése egymástól függetlenül, de ugyanolyan út mentén történik, biztosítva ezzel a vállalat üzleti céljaihoz való pontos illeszkedést. A szervezet saját igényei szerint határozza meg a folyamataiban megcélzott képességi szintet, így az egyes területek

összehasonlíthatóvá válnak. 3. ábra Folyamatos modellértelmezés A képességi szint (CL – Capability Level) egy jól definiált fejlődési szint, amely a szervezet képességeit írja le az adott kulcsfolyamat-terület (KPA – Key Process Areas) vonatkozásában. Hat fokozatot különböztetünk meg, ezek közül az 1-5-re adott egy-egy közös cél. A képességi szintek kumulatívak, azaz a magasabb tartalmazza az alacsonyabb teljesülését Lehetőség van bizonyos folyamatcsoportok vizsgálatára is, ekkor azok képességi szintje adja az úgynevezett „képességi szint profilt” (capability level profile). 10 5.1 Folytonos folyamatjavítás biztosítása 5. Optimalizált 5.2 A problémák kiváltó okainak megszüntetése 4.1 Mennyiségi célok meghatározása a folyamat számára 4. Mennyiségileg menedzselt 4.2 A részfolyamatok teljesítményének stabilizálása 3.1 A definiált folyamat létrehozása 3. Definiált 3.2 Fejlesztési információk

összegyűjtése 2.1 Szervezeti irányvonal meghatározása 2. Menedzselt 2.2 Folyamat tervezése 2.3 Erőforrások rendelkezésre bocsátása 2.4 Felelősségek kijelölése 2.5 Emberek képzése 2.6 Konfigurációk menedzselése 2.7 A folyamatban érdekelt felek azonosítása és bevonása 2.8 A folyamat követése és vezérlése 2.9 A folyamat betartásának objektív kiértékelése 2.10 Állapot szemlézése a felsőbb vezetőséggel 1.1 Alapgyakorlatok végrehajtása 1. Végrehajtott 4. ábra Képességi szintek 3.12 Lépcsőzetes modellértelmezés A szervezet egészét vizsgálja, fejleszti, s egy úgynevezett érettségi mutatót rendel hozzá, mely vállalaton belüli és vállalatok közötti összehasonlítást tesz lehetővé. Az egyes folyamatok fejlesztése szintenként egyszerre, ugyanazon az úton történik. A megkövetelt eljárások köre szintről szintre bővül. 11 5. ábra Lépcsőzetes modellértelmezés Az érettségi szint (ML – Maturity Level)

egy jól definiált fejlődési szint, amely a szervezet érettségét írja le a teljes működése vonatkozásában, azaz azt mutatja meg, hogy mennyire képes a szervezet vállalásait megbízhatóan teljesíteni. 5 érettségi szint van, az egyes szintekhez adott általános (közös) cél megfelel az azonos folyamatképességi szint általános céljának. Az érettségi szintek kumulatívak, azaz a magasabb tartalmazza az alacsonyabb teljesülését.  ML1 – Kezdetleges A szoftverfejlesztési folyamatok végrehajtása „ad-hoc”4 jellegű, ahol a teljesítmény az egyes emberek elszántságán és kompetenciáján múlik. Nincs stabil környezet, a folyamatok végrehajtását befolyásoló, előre nem tervezhető események kezelésére szükségmegoldások születnek. Gyakori a határidő – és költségtúllépés, a siker többnyire a végrehajtó szakember képességein és hozzáállásán múlik.  ML2 – Irányított Az előző szinthez képest a különbség

a folyamatok tervezettségében van, minek folytán a projekt azonos körülmények között megismételhető. A termék elkészítése felügyelet alatt, ellenőrzötten történik, s mérföldkövek definiálásával a folyamat teljesítésének monitorozása is megoldható. Alapvető szoftverfejlesztési tevékenységei közé tartozik a projekt tervezés, konfiguráció – és követelmény menedzsment. 4 Ad-hoc: eseti megoldás, mely nem általánosítható, csak egy speciális problémára ad választ az átfogó rendezés igénye nélkül 12  ML3 – Definiált A szabványok, eljárások szervezeti szinten történő megjelenése lehetővé teszi egy konstans projektminőség elérését. A különbség az előző szinthez képest a folyamatok hatáskörében keresendő. A projektek végrehajtásának mikéntje illeszkedik a szervezet által elfogadott standardokhoz és csak kivételes és előzetesen dokumentált esetekben térhet el ettől. Az egyes eljárások a

változó körülményekre felkészülten reagálnak, mivel tevékenységük és egymással való kölcsönhatásuk szervezeti szinten ismert és dokumentált. A menedzsment feladata, hogy a folyamatokat a meglévő szervezeti kultúrára alapozva egy jól definiált stratégia mentén építse fel.  ML4 – Mennyiségileg menedzselt Mennyiségileg értelmezhető célok és kritériumok jellemzik, lehetőség van a projektek teljesítményének számszerű összehasonlítására, s végrehajtásuk időben, költségben és minőségben is előre tervezhető. A folyamatok tevékenységei közül kiválasztásra kerülnek azok, amelyek jelentősen befolyásolhatják az egyes eljárások, illetve a szervezet teljesítményét. Ezekre a tevékenységekre statisztikai vagy egyéb alapokon nyugvó mérési technikák kerülnek kidolgozásra. A mérési eredmények gyűjtésével, megőrzésével és analizálásával felszínre kerülnek a tevékenység teljesítményét befolyásoló

tényezők, és megtörténik ezek korrekciója. Az egyes folyamatok végrehajtásának kontrollálása és értékelése számszerű célkitűzések meghatározásával történik, amelyeket a megbízó, a felhasználó és a szervezet definiál.  ML5 – Optimalizáló Az ötödik szint a megújuló, inkrementális folyamatfejlesztés révén hoz újítást az előzőhöz képest. Az egyes eljárások végrehajtását befolyásoló tényezők számszerűsíthető hatására alapozva a tevékenységek hatékonysága és a végrehajtás minősége javítható. A folyamatok aktuális teljesítménye összehasonlításra kerül a változó üzleti igények által diktált elvárásokkal, s ez alapján döntenek a megvalósítandó fejlesztésekről. Mindehhez szükség van a szervezet tagjainak motiválására és állandó képzésére, hiszen a performancia javításának minden résztvevő tevékenységének részét kell képeznie. 13 3.2 Szoftver-életciklus modellek A

szoftver-életciklus modell definiálja a projekt végrehajtásának forgatókönyvét. Főbb vonalaiban meghatározza a projektvezetési stratégiát, a projekt menetrendjét, ütemtervét, mérföldköveit, s az alkalmazható szoftverfejlesztési módszertanok körét, amelyek mind a megbízó, mind a munkatársak számára fontos szempontokat tartalmaznak. A következőkben három fő modell kerül bemutatásra, melyeket önmagukban már egyre kevésbé, de komplex módszertanok részeként, egymással kombinálva előszeretettel alkalmaznak. [4] 3.21 Vízesés (Waterfall) modell A klasszikus vízesés modellt az 1970-es években a Lockheed5 cégnél dolgozó Winston W. Royce dolgozta ki Az elnevezés onnan származik, hogy a követelményelemzés, tervezés, implementáció, verifikáció (tesztelés) és kiszállítás szigorúan egymás után hajtandóak végre. Az egyes fázisok befejeződését mérföldkőnek (milestone) nevezzük, amelynek elérését a hozzá tartozó

dokumentum elkészülése jelzi. 6. ábra Vízesés modell 5 Loughead Aircraft Manufacturing Company: 1912-ben alapított repülőeszközöket (repülőgépek, rakéták) gyártó multinacionális cég, mely 1995-ben a Martin Marietta Corporation-el való egyesülése után a Locheed Martin vállalat részeként működött. 14 Hasonlóan a vízhez, ami a gravitáció ellenében nem képes a vízesés lépcsőin visszafelé haladni, ebben a modellben komoly komplikációkat eredményezhet, ha visszamenőleg kell változtatásokat eszközölni. Kizárólag akkor működik kifogástalanul, ha az adott fázis előkövetelményei teljes mértékben ki vannak elégítve Ezen elvárásoknak egyes hardver eszközök gyártása esetén meg lehet felelni, ám a szoftverek komplexitása és a megrendelő állandóan változó igényei miatt informatikai rendszerek esetében csak akkor kivitelezhető, ha rövid határidejű, egyszerűen megvalósítható projektről van szó. 3.22

Iteratív inkrementális modell Az inkrementális modell a tevékenységek iteratív végrehajtására épül. Jellemzője, hogy már az implementáció korai szakaszában rendelkezésre áll a működő rendszer, s minden iteráció egy-egy kibocsátott verzióval végződik. Elve az úgynevezett 80:20 szabály, mely azt jelenti, hogy egy 80%-ban kész megoldás elkészítésére elegendő az idő 20%-a. Mindez elképzelhető úgy, hogy először Vízesés modell szerint elkészítjük a rendszermagot (80%), majd több iterációban funkciókkal bővítjük és javítjuk a produktumot (20%). Alkalmazhatóságának feltételei a konkrétan specifikált célok, jól definiált követelményrendszer, rendszerezett információk és hatékony döntési mechanizmus a megbízó részéről. Az inkrementális modell használata abban az esetben indokolt, ha minél előbb igény van kézzelfogható eredmény megtekintésére. 3.23 Spirál modell A Spirál modellt Dr. Barry Boehm

publikálta 1988-ban „A Spiral Model of Software Development and Enhancement” című írásában. Nem ez volt az első eset, melyben a szoftverfejlesztést iterációs megközelítésben vizsgálták, de ebben a cikkben fejtették ki először a szemlélet fontosságát. A Spirál modell fundamentuma a kockázatkezelés, melynek alapja a projekt során fellépő összes tényező tudatos irányítása és az exogén hatások minimalizálása. A követelményelemzés, a tervezés, az implementáció és az integráció külön-külön további fázisokra bomlik. Az első az információgyűjtés, melynek során a tevékenység lehetséges végrehajtási módjainak és az ezeket befolyásoló tényezők akkumulálása történik. Eredményeképpen alternatívák és döntési szempontok állnak rendelkezésre. Második lépés a kockázatanalízis, az előző pontban összegyűjtött alternatívák vizsgálata. A fázis végén kiválasztásra kerül egy végrehajtási mód, és

kijelölik annak időhatárait. 15 A harmadik szakaszban történik az előző pontban választott megoldás teljesítése. A tevékenység befejeztével előáll az egyértelműen meghatározott és dokumentálható eredmény. Legvégül megtörténik a választott alternatíva eredményének értékelése, a tapasztalatok rendszerezett publikálása, s döntés a következő tevékenységről. 7. ábra Spirál modell A modell jellemzője, hogy a folyamatot a kockázati tényezők elemzése után hozott döntések befolyásolják. Az egyes tevékenységek súlya az egymás utáni iterációs lépések során a körülményektől függően változik. Alkalmazása olyan komplex projektek esetében javasolt, ahol bizonytalanok a célok, nincs egyértelmű követelményrendszer, nehéz az információ megszerzése és rendszerezése, lassú a döntési mechanizmus, nagyméretű a projektszervezet és új technológiák megismerése szükséges. 16 3.3 Agilis

szoftverfejlesztési módszertanok A rendszerek bonyolultságának és a projekthez szükséges munkaerő nagyságának növekedésével a klasszikus életciklus-modellek és módszertanok egyre kevésbé alkalmazhatók sikeresen az szoftverfejlesztésben. A hagyományos prediktív „megtervezem, majd legyártom” jellegű munkafolyamat legtöbbször nem működőképes, mivel a követelmények hétről hétre változnak a megbízó újabb ötleteinek következtében. A megoldást a változásokhoz könnyen alkalmazkodó „adaptív” módszerek jelentik, amik a hagyományosnál nagyobb hangsúlyt fektetnek az emberközpontúságra, kommunikációra és gyors visszajelzésre. Használatukkal szorosabb együttműködés alakítható ki a projekt csapat tagjai között és hatékony csoportmunka valósítható meg. [5] Az Agilis Fejlesztés egy gyűjtőnév, mely alá több konkrét módszertan is tartozik, melyek között találhatók szoftverfejlesztésre és menedzsmentre

használható típusok is. Alapja a 2001-ben 17 ember által megalkotott Agilis Kiáltvány, amit széles körben elfogadtak, mint az agilis fejlesztés kanonikus meghatározását: Az Agilis Kiáltvány A szoftverfejlesztés jobb módjait fedezzük fel azáltal, hogy csináljuk, és segítünk másoknak is csinálni. Ennek során az alábbi hangsúly-eltolódásokat találtuk: Egyének és interakcióik, szemben az eljárásokkal és eszközökkel. Működő szoftver, szemben a teljes körű dokumentációval. Együttműködés az ügyféllel, szemben a szerződésről való alkudozással. Változásokra való reagálás, szemben a terv követésével. Ez azt jelenti, hogy a jobb oldalon szereplő értékek is fontosak, de a bal oldalon lévőket fontosabbnak tartjuk. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken

Schwaber, Jeff Sutherland, Dave Thomas 2001, a fenti szerzők 17 3.31 Az agilis módszertanok alapelvei  a megrendelő kielégítése a szoftver gyors és folyamatos szállításával  két-háromhetente működő verzió átadása az ügyfélnek  a folyamat fő mérőegysége a működő szoftver  a fejlesztés késői szakaszában történő követelmény-változások is elfogadottak  szoros, napi szintű együttműködés a fejlesztők és a menedzsment között  a szemtől szembe történő kommunikáció preferálása  a projekt motivált, megbízható egyénekre épül  a tervezés és technológiai megvalósítás minőségének maximalizálása  egyszerűség  önszervező csapatok kialakítása  állandó alkalmazkodás a változó körülményekhez 3.32 Összehasonlítás a hagyományos módszertanokkal Az eddig ismertetett modellekkel való összehasonlítás alapját az alábbi ábra szemlélteti: 8. ábra

Módszertanok összehasonlítása A számegyenesen látható, hogy két véglet különíthető el: az adaptív és a kiszámítható módszertanok. Az adaptív módszertanok a gyakran változó követelményekhez való alkalmazkodásra fókuszálnak. Nehezen tudja megmondani, hogy mi fog történni a jövőben, és minél távolabbi időponttal kapcsolatban kell meghatározni az eseményeket, annál bizonytalanabb. Az adaptív módon működő csapatok hajszálpontosan meg tudják mondani, hogy mit fognak csinálni a jövő héten, a következő hónappal kapcsolatban a fejlesztendő funkciók listájáról tudnak nyilatkozni, fél évre előre pedig csupán költségbecslésekkel tudnak szolgálni. A kiszámítható módszertanok arra fókuszálnak, hogy a legapróbb részletekbe menően, minél részletesebben megtervezzék a jövőt. A csapat bármikor meg tudja mondani, hogy milyen feature-ök mikorra lesznek kész a projektben, viszont emiatt nehezen váltanak irányt. A terv a

meghatározott cél elérésére van optimalizálva, ennek következtében egy komolyabb módosítás 18 azt eredményezheti, hogy az egész addigi munkát el kell dobni és újra kell kezdeni. Az ilyen esetekre változáskezelő bizottságot szoktak felállítani, aminek feladata biztosítani, hogy csak a legszükségesebb módosítások érintsék a projektet. Az agilis módszertanok az iteratívhoz hasonlóan bizonyos időközönként kiadnak egy működő verziót, ám két változat elkészülése közti időköz nem hónapokban, hanem hetekben mérhető. További különbség, hogy a határidő kőbe van vésve és nem változhat Abban az esetben, ha mégis kicsúsznak az időből, új feladatot kreálnak, ha szükséges, egyszerűsítik a funkcionális követelményeket. A következő szakaszban példaként a Scrum módszertan bemutatása következik, külön kiemelve a benne rejlő újdonságokat. 3.33 Scrum A Scrum egy szoftverprojektek menedzselésére kialakított

módszertan, de karakterisztikája, alapelvei és terminológiája alkalmassá teszik más területeken való sikeres alkalmazásra is. Az agilis metodológiákra jellemző alapelveknek köszönhetően hatékony csoportmunka valósítható meg segítségével. A modellben hat szerepkört különböztetünk meg, melyek két, három elemből álló halmazra bonthatók. Az első csoportba tartoznak azok, akik mindent beleadnak a projektbe (Terméktulajdonos, Scrum Master, Csapat), a másodikba pedig azok, akik kevésbé érdekeltek benne (Felhasználók, Stakeholder-ek, Menedzserek). Az utóbbi nem része magának az aktuális Scrum folyamatnak, de bevonják őket a fejlesztésbe, építenek a tőlük érkező visszajelzésekre. Terméktulajdonos (Product Owner) A megrendelőt személyesíti meg. Döntéseket hoz a követelményekről, üzleti szempontokat tartva szem előtt. A csapat számára mindig elérhetőnek kell lennie Scrum Master Az elnevezéssel ellentétben nem a csapat

vezetője. Feladata, hogy elhárítsa az akadályokat a fejlesztők elől, hogy azok minél hatékonyabban tudják végezni a munkájukat. Betartatja a szabályokat, célja a produktivitás növelése bármilyen lehetséges módon, s biztosítja a csapat elszigetelését a terméktulajdonostól. Csapat (Team) A csapat felelőssége a termék határidőre történő elkészítése. Az évek során felgyülemlett tapasztalat azt mutatja, hogy 5-9 fős létszám esetén érhető el az optimális működés. Összetétele vegyes, különböző feladatköröket betöltő egyénekből áll: fejlesztők, designer-ek, tervezők, 19 tesztelők, stb. A csapat dönti el, hogy az adott feladatot milyen módszerrel oldják meg, ebből következik, hogy övék a felelősség is. Az emberközpontú fejlesztés és a hatékonyság növelése végett gyakran egy légtérben végzik munkájukat. Felhasználók (Users) Ők azok, akik használni fogják a terméket. A fejlesztés során lehetőséget

kell adni nekik, hogy kipróbálják az egyes változatokat és gyors visszacsatolást adjanak a hibákról. Stakeholders Azok a személyek, akik kellenek a szoftver létrejöttéhez, de nem vesznek részt közvetlenül a folyamatban. Többek között a vásárlók, illetve beszállítók, vendorok tartoznak ide Menedzserek (Managers) A menedzserek felelősek a termék fejlesztéséhez szükséges infrastruktúra megteremtéséért. Gondoskodniuk kell a csoportmunkát elősegítő körülmények biztosításáról és az ezzel kapcsolatos pénzügyek adminisztrációjáról. A bemutatott szerepköröket betöltő csapattagok tevékenységét a Scrum módszertan karakterisztikája határozza meg. A projekt első fázisa a tervezés, amikor létre kell hozni az architektúrát és ki kell nevezni egy főtervezőt. Fel kell készülni arra, hogy az itt definiált szerkezet a követelmények módosítása miatt megváltozhat. A kezdeti tervezés után a fejlesztési fázisok sorozata

következik, melyeket sprint-eknek nevezünk. Ennek során inkrementálisan, 1-4 hetes időtartamú szakaszokban jön létre a termék A csapat nyomon követi az összes feladatot, melyet listában kapnak meg, ez a backlog. Két típusa van: product backlog és sprint backlog. A product backlog-ban találhatóak a funkcionális, nem funkcionális és a csapat által létrehozott követelmények prioritásuknak megfelelő sorrendben. A prioritások meghatározása a terméktulajdonos felelőssége. A lista elemeit a product backlog item-ek képezik, melyek az egy-egy sprint során elvégzendő feladatokat tartalmazó sprint backlog-okba kerülnek. A sprintek előtt kerül sor a sprint planning meeting-re, ahol a csapat frissíti a backlog-ot és újra-priorizálja a benne lévő feladatokat. Minden csapattag kiválaszt egy feladatot, amit saját bevallásuk szerint meg tudnak csinálni, majd megbecsülik a végrehajtáshoz szükséges időt. A Scrum Master ezen értékek alapján

meghatározza a sprint végét. Ezt az időpontot nem lehet módosítani, csupán az adott sprintre tervezett funkcionalitást lehet csökkenteni. A fejlesztők minden nap frissítik az úgynevezett sprint burndown chart-ot, amely a sprint végéig hátralévő órák számát tartalmazza. 20 A sprint során a csapat minden nap előre meghatározott időben Scrum meeting-et tart. A megjelenés kötelező, a hiányzókat előre megbeszélt szankciókkal sújtják. A találkozókon minden résztvevőnek három kérdést kell megválaszolnia:  Mit csinált tegnap óta?  Mi a terve mára?  Van-e valami, ami akadályozza ebben? A kérdések egyszerűek, mégis átfogó képet adnak a fejlesztési folyamat állapotáról. A scrum meeting nem brainstorming6, nem old meg problémákat, ellenben rövid ideig tart és csapatépítés jellegű. A sprint végén van az úgynevezett sprint retrospective meeting, melynek célja, hogy a csapat és a Scrum Master megbeszéljék az

utolsó fázisban történteket. Meg kell vizsgálni, mi az, ami jól működött, és min kell javítani a következő sprint során, ezzel is növelve a csapat teljesítményét. Az új sprint elkezdéséhez frissítik a product backlog-ot és következik az újabb fázis, egészen a végleges termék elkészültéig. A Scrum metodológia menedzselésére több megoldás is született egészen a felragasztható sárga emlékeztetőtől a modern whiteboard-ig. Mindebből és az eddig leírtakból is következik, a módszertan legnagyobb előnye, hogy könnyű megtanulni, és nem szükséges kockázatos, drága befektetéseket eszközölni használatához. A Scrum csak egy az agilis módszertanok közül. Ide tartozik még az Extreme Programming, Feature Driven Development, DSDM és még egyéb metodológiák, melyek az alapelveknek köszönhetően hatékonnyá és ügyfélközpontúvá teszik az informatikai szervezetek működését. 6 A brainstorming egy csoportos ötletelési

technika, melynek célja megoldások keresése egy adott problémára 21 3.4 MSF – Microsoft Solutions Framework A Microsoft Solutions Framework információtechnológiai megoldásokat, alapelveket, modelleket, irányelveket és eljárásokat tartalmazó rendszerezett gyűjtemény. Az MSF útmutatásait túlnyomó többségben szoftverfejlesztési projektekben alkalmazzák, mindemellett használata kiszállítási, hálózati és infrastrukturális feladatok megoldásakor is tetten érhető. A dolgozatnak nem célja e keretrendszer minden igényt kielégítő ismertetése, ezért a következőkben a szoftveriparban fontos tulajdonságai és csoportmunkát támogató megoldásai kerülnek bemutatásra. [6], [7] 3.41 Az MSF alapelvei A Microsoft Solutions Framework alapelvei a kiemelkedően hatékony fejlesztői csoportok viselkedését írják le. Annak ellenére, hogy az egyes útmutatások követése önmagában is pozitív változásokat eredményez, fontos tudatosítani,

hogy ezek együttesen alkotják az MSF filozófiáját. Az irányelvek lehetővé teszik az ipari szereplők számára, hogy a szervezet belső struktúráját és a folyamatokat következetesen, egyetlen vezérfonal mentén építsék fel a projektek sikeres teljesítése érdekében. Az ügyfelekkel való jó partnerkapcsolat a közös munka elejétől kezdve meghatározza a végtermék minőségét. A nyílt információáramlás biztosítása, a megoldás értékének ismerete és hatékony kommunikálása a siker alapvető tényezője. A csapattagok munkájának maximalizálásához biztosítani kell az információ elérhetőségét mindenki számára. A csoportmunkát támogató fejlesztői rendszerek segítségével nyomon követhetők a hibák, feladatok, dokumentációk, és egyéb, projekttel kapcsolatos tudnivalók. Ösztönözni kell a csoport tagjait, hogy felülemelkedjenek a bizonytalanságtól való félelmükön és ne csak a dolgok jelenlegi állása kösse le

figyelmüket. Tudatosítani kell mindenkiben, hogy miért felelős mint egyén, s mi az a jövőkép, aminek eléréséért részt vállal a fejlesztői közösség munkájából. Hosszútávra szóló, korlátok nélküli elképzelések megvitatásával növelni lehet a tagok lelkesedését és megszilárdítani a csapatszellemet. A termék magas színvonalának biztosítása végett mindent meg kell tenni a hibák megelőzése érdekében. Különböző eljárásokkal, például kódellenőrzéssel, egymás munkájának átnézésével, a legjobb megoldás közös kiválasztásával biztosítható a produktum helyes működése. Szem előtt kell tartani, hogy a hibák felderítése és igazolása szereptől függetlenül mindenkinek a felelőssége. A felderített rossz megoldásokat közösen meg kell vizsgálni, s a csapat minden tagját arra ösztönözni, hogy tanuljon ezekből. 22 A minden részletre kiterjedő projekttervek és az ügyféllel való pontos

egyeztetés ellenére egy informatikai rendszer fejlesztésekor elkerülhetetlen, hogy menet közben ne változzon meg az üzleti igény kisebb vagy nagyobb funkcionális egységekre vonatkozóan. Az előre nem látott helyzetekhez és módosításokhoz való alkalmazkodás kiemelt fontossággal bír, ugyanis elősegíti a szervezet technológiai befektetéseiben az üzleti hatás maximalizálását. Az egyes kiadásokban szem előtt kell tartani, hogy az ügyfél fokozatosan nagyobb értékhez jusson, befektetései egyre nagyobb mértékben térüljenek meg. Minimalizálni kell azokat a tevékenységeket, melyek nem termelnek értéket. Tanácsolt a terméket iterációkban elkészíteni, hogy a megbízónak lehetősége legyen a változások értékelésére és az esetleges további módosítások megvitatására. A projektnek nem szabad időt veszítenie azzal, hogy a csapattagok teljes komplexitásukban akarják kezelni a problémákat. Megoldható feladatokat kell elvégezni,

egyszerre csak egyet, s mindvégig szem előtt tartani, hogy a jövőben a kézzelfogható eredményekből jobban tanulhatunk, mint az elvontból. A projekt megfogalmazásának egyértelműnek, lehetőleg hétköznapi nyelvi szintűnek kell lenni, hogy mindenki számára világosak legyenek a célok, ugyanis e nélkül nem lehet működő kódot írni, megfelelni a teszteknek és telepítésre kész kiadásokat létrehozni. A fenti alapelvek és útmutatások mellett kiemelt fontossággal bír, hogy a szolgáltatás minőségét - melybe beletartozik a teljesítmény és a biztonság - mindvégig magas szinten kell tartani az ügyfél elégedettségének és a jó hírnév fenntartásának érdekében. 3.42 Az MSF csapat – és folyamatmodellje A szoftverfejlesztéssel foglalkozó cégek sikerességét nagyban befolyásolja a végrehajtó szervezet felépítése és a folyamatok végrehajtási módja. Az MSF modelljei erre a két területre fókuszálva és valós tapasztalatokra

építve definiálják egy projekt szervezeti felépítését és egy projekt folyamatait a szoftver-életciklus alatt. A modellek az előzőekben már tárgyalt alapelvekre épülnek, s az eljárásokat és irányelveket a következetes végrehajtás szellemében fogalmazzák meg.  Az MSF csapatmodellje A csapatmodell a projekt résztvevőinek szerepkörét, a hozzájuk tartozó felelősséget és a köztük lévő összefüggést határozza meg. Alapja az egyenrangúság, egyik csapattag sem fontosabb a másiknál, hierarchia egyedül a beszámolások esetén figyelhető meg, ahol az egyes csapattagok az általuk képviselt felelősségi terület szószólójaként lépnek fel. Ezzel a megközelítéssel csökkenthető a kockázat, mert olyan biztosítékrendszert hoz létre, mely a 23 csapatot mindig a helyes megoldás felé irányítja. Az MSF csapatmodell hét területet ölel fel, melyek az következőkben kerülnek bemutatásra. 9. ábra MSF Csapatmodell

Termékmenedzsment A termékmenedzser képviseli az ügyfél érdekeit, ő felelős a megbízó elégedettségéért. Feladata a marketinggel kapcsolatos ügyintézés, az üzleti értékek definiálása, partnerkapcsolatok kezelése és a termékvonal kialakítása. Programmenedzsment A programmenedzser a projektkövetelményeknek megfelelő szállításért, a tervezett határidők és költségek betartásáért felelős. Szerepkörének hatókörébe tartozik a projektvezetés, rendszertervezés, garancia és jótállás az ütemterv teljesítésére, illetve egyéb adminisztrációs tevékenységek. Architektúra Az architekt a rendszer egészének képviselője. Szerteágazó tudással rendelkezik a legelterjedtebb szoftvertechnológiákkal kapcsolatban, melyek közül képes kiválasztani a projekt számára legalkalmasabb változatot, esetleg ötvözetet. Felelős azért, hogy a megoldás megfeleljen az üzletben vagy a termékcsaládban elfoglalt helyének, képes

legyen együttműködni más szolgáltatásokkal és kompatibilis legyen azzal az architektúrával, amibe végül telepítik. 24 Fejlesztés A fejlesztők felelősek a működő produktum létrehozásáért, egzakt módon fogalmazva a kód megírásáért. Szerepkörük kiterjed technológiai tanácsadásra, prototípus tervezésre és implementálásra illetve becslések készítésére a projektmenedzsment számára. Feladatuk a szoftvermegoldás megtervezése, létrehozása és integrációja a választott környezetbe. Tesztelés A tesztelők a produktum minőségét képviselik az ügyfél szemszögéből. Feladatuk a teszttervek elkészítése, tesztelés elvégzése, problémák azonosítása és jelentése, végül az eredmények dokumentálása. A szerepkör felelőssége, hogy minden hibát megtaláljanak, mielőtt a termék a megrendelőhöz kerül, továbbra is biztosítva a pozitív benyomást és fenntartva a jó hírnevet. Felhasználói élmény Az ebben a

szerepkörben dolgozó csapattagok a felhasználó szemével tekintenek a termékre. Az ő felelősségük a felhasználói kontextus átfogó megértése, és a csoport többi tagjának erre való ösztönzése. Feladatuk, hogy tartsák a kapcsolatot a végfelhasználókkal, oktatásokat rendezzenek, ergonómiai tanácsokat adjanak mind a fejlesztőknek, mind a megrendelőknek, hatékonyság-központú szemléletet követve kialakítsák a felhasználói interfészt, s igény esetén honosítsák – többnyelvűsítsék azt. Kiadás és üzemeltetés A kiadással és üzemeltetéssel foglalkozó csapattagok felelőssége a zökkenőmentes átadásnak és a megoldás telepítésének biztosítása. Feladatuk az infrastruktúra kialakítása, rendszertámogatás, üzemeltetés és kapcsolattartás a szolgáltatókkal, beszállítókkal, üzemeltetőkkel. A fenti modell alapján történő csapatépítéshez az MSF a következő irányelveket definiálja: vevőközpontúság,

termékközpontúság, törekedés a tökéletességre, hajlandóság a tanulásra és állandó motiváltság a maximális hatékonyság eléréséhez. Ezek teljesítése akkor lehetséges, ha kicsi, de szerteágazó szakértelemmel bíró csapatot alakítunk ki, ahol minden szerepkör kollektíven részt vesz a tervezésben. 25  Az MSF folyamatmodellje Az MSF folyamatmodell egy szoftver-életciklust és annak a fázisait definiálja, mely szemléletében a Vízesés és a Spirál modell elveit ötvözi. A projektvezetés szemszögéből az előre kijelölt mérföldkövek teljesítésére, a termékfejlesztés nézőpontjából pedig az iterációkra épülő inkrementális teljesítésre törekszik. Szerepek A Megbízó(Customer) finanszírozza a projekt végrehajtását és saját üzleti értékének növekedését várja a leszállítandó terméktől. Feladata a követelmények tisztázása, és a kivitelezés ellenőrzése. A teljesítés feltételeit szerződésekkel

és megállapodásokkal kell rögzíteni. A Felhasználók a Megbízó által megrendelt terméket használó személyek. Fontos szem előtt tartani, hogy az egyes verziók vizsgálatába őket is be kell vonni, mert a produktum értékét az ő visszajelzéseik is nagyban befolyásolják. Az Érdekelt fél szerepkörbe a projekt során érintett személyek vagy csoportok tartoznak. Érdekeltségüket és elvárásaikat azonosítani kell, hogy a folyamat végén előálló végtermék az ő igényeiknek is megfeleljen. Fázisok, mérföldkövek A mérföldkövek szinkronizációs pontként szolgálnak, ahol a különböző szerepkörökben dolgozó csapattagoknak kiosztott feladatok eredményei összehangolhatók a megrendelő elvárásaival, s elvégezhetők a szükséges korrekciók. 10. ábra MSF Folyamatmodell 26 A modell a feladatok teljesítésére a verziózott kibocsátáson alapuló iteratív megközelítési módot javasolja. Ezzel biztosítható a folyamatos tanulás

és finomítás, csökken a becslések hibahatára, s lehetőség van a termék szakaszos tesztelésére és szállítására. Az egyes verziókban meghatározható, hogy milyen funkcionalitással kell rendelkeznie a rendszernek, így elkerülhető a felesleges komponensek elkészítése. A fokozatosan fejlődő változatok gyakori információ-visszacsatolást tesznek lehetővé a fejlesztők, a menedzsment és a megrendelő között. A rendszermag gyors kipróbálásával már a kezdetekben tisztázhatók az esetleges félreértések, mellyel rengeteg fejlesztési költség takarítható meg. Az első iteráció az új projekt inicializálásával foglalkozik: projekttervezés és a fejlesztői illetve tesztelői környezet kialakítása. Az ezt követő körökben a rendszer funkciói kerülnek megvalósításra. Egy-egy iteráció végeredménye lehet kiadatlan alfa-tesztverzió, vagy nyilvánosan tesztelt béta, melyről a felhasználói közösség küld visszajelzéseket a

készítők számára. A funkcionalitást célzó kiadások mellett telepítési eljárások tesztelése is folyik, hogy a végleges változat elkészültével egyből el lehessen kezdeni a kiszállítást. Az utolsó iterációban a termék befejezi a fejlesztési fázist, s átlép a termelési fázisba. A végső átmenet magában foglalja a végső tesztelést és a telepítést. A leírtak alapján jól látszik, hogy a Microsoft Solutions Framework használható alternatívát nyújt a piacon jelenlévő szoftverfejlesztő cégek számára, hogy ipari tevékenységüket egy csoportmunka-folyamatokat használó komplex módszertannal tegyék hatékonyabbá. Az alapelveknek, a jól definiált szerepköröknek és az együttműködésüket segítő folyamatmodellnek köszönhetően a projekt kézben tartása és koordinációja kevesebb erőfeszítést igényel, nem vesz el időt és figyelmet a feladatok végrehajtásától. 27 4. Microsoft csoportmunka megoldások A

dolgozat előző fejezetei ismertették a groupware rendszerek fő tulajdonságait, követelményeit, illetve a szoftveriparban alkalmazott alapvető eljárásokat, metodológiákat, kiemelve némelyiket részletesebb vizsgálat céljából. Ebben a szakaszban a Microsoft csoportmunkát, munkafolyamatokat és üzleti intelligenciát támogató eszközei kerülnek bemutatásra. Elsőként az alkalmazásfejlesztés módszertanait szoftveresen támogató Team Foundation Server, majd az univerzális felhasználású SharePoint Server 2007 és Windows Workflow Foundation ismertetésére kerül sor. A felsorolt technológiák az informatika újdonságait befogadó és tudatosan használó csoportok számára kínálnak kész megoldásokat a kommunikáció, kollaboráció és koordináció magas szintű megvalósításához. 4.1 Team Foundation Server A szoftverfejlesztési metodológiák és ajánlások követése, a szabályok betartása és a projekt minden területének kézben

tartása nem biztosítható megbízható szoftveres támogatás nélkül. A Visual Studio Team System7 részét képező Team Foundation Server a munkaelemek, forráskódok és egyéb erőforrások megosztásával teszi lehetővé a szervezet tagjainak együttműködését és koordinálását. [6] Az eszköz az alábbi szolgáltatásokat bocsájtja a csapat rendelkezésére:  Projektmenedzsment  Portál  Munkaelem-követés  Változáskövetés  Fordítókiszolgáló  Jelentések 4.11 Projektmenedzsment A csapatalapú szoftverfejlesztés alapja a tagok összehangolt tevékenykedése, figyelve vezetőjüket, hogy időre elkészüljenek a kiadásra kész termékkel. A menedzsereknek mindig ismerniük kell a projekt állapotát: mennyi kódváltozás van a napi fordításokban, mikor érte el a projekt a nulla hibaszámot, s megbeszélések alkalmával ezeket számon kérni a csapattagoktól. A csoport kommunikációját és a Team Foundation Server

szolgáltatásaihoz való hozzáférést a 7 A Visual Studio Team System a Microsoft szoftverfejlesztést, csoportmunkát és riportkészítést támogató eszközeinek gyűjteménye. 28 Team Explorer elnevezésű eszköz biztosítja, mely minden, a Team System részét képező szoftverben megtalálható. A választott módszertantól függően a szoftverfejlesztéshez való hozzáállás eltérő lehet, de minden esetben törekedni kell az információk intelligens módon történő eltárolására. Ennek támogatására a Team Foundation Server a csapat-projekt elnevezésű komponenst kínálja fel, mely egységes szabályrendszerbe foglalva írja le a munkafolyamatokat, azok szereplőit és kapcsolatait. Alkalmazásával kialakíthatók a szabványos módszertanokat megvalósító sémák, melyek közül a projektek indulásakor a természetüknek leginkább megfelelő típusból készül el a működésre kész példány. A vezetők a folyamat egész ideje alatt

felügyelhetik a sablonban definiált komponensek működését, mindig különös figyelmet szentelve a csapat és a szoftver egyébként is törékeny kommunikációjára. 4.12 Portál A vastagkliensekbe integrált Team Exploer-en kívül létezik webes megoldás is a csapatkommunikáció fenntartására. A következő fejezetben részletesen tárgyalt Windows SharePoint Services segítségével könnyen létrehozható egy csoportmunka-portálkörnyezet bármilyen méretű csapat számára. A website lehetővé teszi a projekt folyamatainak nyomon követését, a munkaelemek és generált riportok megtekintését és a csapattagok közötti kapcsolat fenntartását. A böngészőben való megjelenés nagyszintű platformfüggetlenséget biztosít, így azok is tevékenyen részt vehetnek a projekt életciklusában, akik nem élhetnek a Team Explorer szolgáltatásaival. A Team Foundation Server által generált alapértelmezett, letisztult tartalomstruktúra és megjelenés az

adminisztrátor által tetszőlegesen megváltoztatható. 4.13 Munkaelem-követés A munkaelem bármely, a szoftverfejlesztési életciklushoz tartozó, konkrét tevékenységhez köthető információt meghatározhat, mint például a követelmények, a feladatok és a hibák. Tulajdonságaik részletes információval szolgálnak címükről, létrehozásuk időpontjáról, állapotukról és a csapattag nevéről, akihez hozzá lett rendelve. Ezek lesznek a szoftverfolyamat alapjai, melyek a projekt minden fázisában és iterációjában együtt mozognak a felhasználókkal. A munkaelemek aktuális típusát és formátumát a projekthez kiválasztott módszertan határozza meg. A gyakorlatban ez azt jelenti, hogy más bejegyzések jelennek meg például Agilis irányultságú, vagy a CMMI-t alkalmazó ajánlások esetén. A különbségek ellenére minden esetben igaz, hogy a fejlesztési folyamat során más objektumokhoz kapcsolhatóak (például programkód,

dokumentáció), melyek segítségével a projektvezető nyomon tudja 29 követni, mely változások tartoznak az egyes követelményekhez vagy hibákhoz. A hozzárendelések lekérdezhetők, jelenthetők, ezzel mindig megállapítható a rendszerben végzett tevékenységek felelőse. Az alapértelmezett projektsablonok által meghatározott munkaelem mezők nincsenek kőbe vésve, mind tartalomban, mind megjelenésben testre szabhatók. A Team Foundation Server rugalmassága ellenére vannak alapvető szabályok, melyek nem kerülhetők meg, mert részei a működést meghatározó metamodellnek:  A felhasználók biztonsági csoportokhoz tartoznak  A felhasználók munkaelemeket birtokolnak  A szerepek munkafolyamatokat végeznek  A munkafolyamok aktivitások sorozatai  A munkaelemek nyomon követik az aktivitást  Az aktivitások munkatermékeket hoznak létre és használnak  Az iterációk csoportosítják és ütemezik a munkaelemeket 4.14

Változáskövetés A Team Foundation Server-be betöltött adatok változását a verziókezelő komponens menedzseli. Az általa bevezetett változáskészletek alkalmazásával elegendő az összetartozó fájlmódosítások leírása, mely elősegíti a jobb könyvelést és munkafolyamatot, valamint egyszerűsíti az adminisztrációt. A forrásfájlokat minden fejlesztő a saját munkaterületén módosítja, mely a számítógépén, lokálisan foglal helyet. A feladat elvégzését követően visszatölti munkáját a szerverre, hozzácsatolva a változáskészletet egy vagy több elemhez, például hibához vagy feladathoz. Az elágaztatás elnevezésű funkció segítségével elemek mozgathatók projektek között, intelligens módon, ügyelve a tárhely-kihasználásra. Ez a képesség lehetővé teszi a több fordítás és kiadás hatékony kezelését, s a fejlesztő egyszerre több ágon is dolgozhat párhuzamosan. Az saját munkaterületen elkészített (forrás) és a

szerveren helyet foglaló (cél) kód egyesítése az összefésülés folyamata során történik meg. A több fejlesztő által, egyidejűleg módosított fájlok feltöltéskor konfliktus eredményezhetnek, melynek feloldására a verziókezelő tesz javaslatokat. A csoportmunka hatékony működéséhez nem csak jó szervezés, de a tagok által tanúsított fegyelem is szükséges. Mivel az emberek mentalitása egyénenként más és más, szabályok alkalmazásával kell azt biztosítani. A beadási házirendek pontosan ezt a célt szolgálják. A fejlesztők rákényszeríthetők, hogy kódjukat csak fordítási hiba nélkül, statikus és egységtesztek elvégzése után, munkaelemekhez hozzácsatolva tölthessék fel a szerverre. 30 4.15 Fordítókiszolgáló A fordítás a fájlok, könyvtárak és komponensek lefordítására vonatkozik, melynek eredményeképpen végrehajtható fájlok, könyvtárak vagy komponensek keletkeznek. Kisebb alkalmazások esetén elegendő

ezt a fejlesztőeszközben elvégezni, de nagy, szerteágazó szoftverprojektekben szükség van további műveletek végrehajtására:  verziókezelt fájlok kivétele a fordításhoz  statikus elemzés, egységtesztek vagy mindkettő futtatása  források fordítása  kódváltozások elmentése, tesztelés, kódlefedettség és más fordítási információk  a bináris fájlok előre meghatározott helyre másolása  jelentések generálása A folyamat többnyire napi vagy heti rendszerességgel fut le, ideális esetben egy külön erre a célra felkészített kiszolgálón. Mivel a piacon maradás egyik feltétele a minél több platformon való jelenlét, több fordítást is el kell végezni párhuzamosan az eltérő felépítésű eszközök optimalizálása végett, lehetőség szerint fizikailag elszeparált szerverkörnyezetben. 4.16 Jelentések A Team Foundation Server adatainak tárolását az SQL Server 2005 adatbázis-kezelő rendszer

végzi, melynek riportkészítő funkciója állítja elő a menedzserek és vezetők számára fontos kimutatásokat. A projekt állapota, a kódváltozás, a lefutott tesztek, a teszthatékonyság, az aktív hibák és a hatékonysági jelentések mind olyan információkat hordoznak, mely elengedhetetlen a fejlesztői munka nyomon követéséhez és javításához. Az SQL Server részeként érkező Reporting Services olyan továbbfejlesztett üzleti intelligenciát és trendelemző képességekkel is rendelkezik, mely a jövő alakulásával kapcsolatban is képes becsléseket előállítani. A Team Foundation Server a felsoroltakon kívül még számos hasznos szolgáltatást nyújt, melyek túllépik a dolgozat kereteit. Az ismertetett rendszer minden kétséget kizáróan alkalmas a sok fő bevonásával történő csoportmunkára, melynek dinamizmusát a szoftveresen támogatott munkafolyamatok határozzák meg. Az informatika világában a groupware hatékonyságát már

mindenhol felismerték, de más szakterületeken még mindig nélkülözik alkalmazását. A következő fejezetekben az általános célú felhasználást támogató eszközök kerülnek bemutatásra. 31 4.2 SharePoint Server 2007 4.21 Az igény kialakulása Az informatika újdonságaival távolságtartó vállalatok életében mindig elérkezik az idő, mikor a működésüket meghatározó elavult technológiák már nem szolgálják ki kellőképpen a felhasználói igényeket. A felhalmozott dokumentumok, hivatalos iratok rendszerezése és egymás közötti megosztása egy bizonyos mennyiség fölött nem oldható meg hatékonyan fájlszerverek alkalmazásával, s főleg nem nyomtatott formában történő elhelyezéssel. Az üzleti folyamatok e-maileken keresztül történő menedzselése rövidtávon megoldható, de sok párhuzamosan futó, több együttműködő fél interaktivitását követelő ügymenet esetén nehézségek adódhatnak. A probléma megoldását

sokáig vastagkliens alkalmazások jelentették, melyeket a cég igényeinek megfelelően a vállalat számítógépei által használt platformra (Windows, Linux) lefejlesztettek, majd kliens-szerver architektúrát alkalmazva telepítettek. Már első ránézésre megállapítható, hogy a módszer több hátránnyal és korlátozással rendelkezik, melyek közül a kettő különösen kellemetlen:  a kliensprogramot minden gépre külön kell installálni, s a frissítések, új verziók letöltése is többletmunkát igényel  ha a cég költségmegtakarítási/technológiai szempontok által vezérelve operációs-rendszert akar váltani munkaállomásain, akkor le kell fejleszteni újra az alkalmazást, vagy virtuálisan futtatni, amihez komoly hardverkövetelmények társulnak A webes technológiák fejlődésével megszületett az igény olyan alkalmazások készítésére, melyek internetböngésző használatával érhetőek el, s az asztali szoftverek

funkcionalitását képesek prezentálni. A vastagkliensek két, a fentiekben felsorolt hiányossága ezzel a megoldással orvosolható:  installálni és a frissítéseket telepíteni csak a központi szerverre kell, a kliensek számára egyből az új verzió válik elérhetővé  bármely operációs-rendszer esetén futtatható, ahol rendelkezésre áll a tartalom megjelenítéséhez szükséges böngésző szoftver A Microsoft által fejlesztett, a .NET keretrendszer részét képező ASPNET technológia valósítja meg azt a komplex, csoportmunkát, munkafolyamatokat és üzleti intelligenciát támogató szoftverrendszert, melynek neve: SharePoint Server 2007. 32 11. ábra SharePoint Server 2007 A MOSS 20078 a kiszolgáló-szolgáltatások olyan integrált készlete, amely egy átfogó tartalomkezelési és vállalati keresőrendszerrel, a megosztott üzleti folyamatok gyorsításával, valamint az információk szervezeti határokon keresztüli, jobb üzleti

átláthatóságot biztosító megosztásával hatékonyabb működést tesz lehetővé a szervezetek számára. A SharePoint Server a cég intranetes, extranetes és internetes web alkalmazásait részekre osztott rendszerek helyett egyetlen integrált platformon támogatja. A kiszolgáló-felügyelethez, alkalmazások bővítéséhez és a közös munkához szükséges eszközöket logikusan felépített felületeken és jól definiált interfészeken keresztül bocsájtja az informatikai szakemberek és fejlesztők rendelkezésére. 4.22 A SharePoint szolgáltatásai A MOSS 2007 alapját a Windows Server 2003 SP1-el megjelent, Windows SharePoint Services 3.0 képezi A WSS 30 egy weboldalak készítésére, dokumentummenedzsmentre, együttműködésre és tartalompublikálásra használható ingyenes objektummodell, mely csak a Microsoft szerver operációs-rendszereiben elérhető. A WSS elsősorban kisebb cégek, csoportok számára jelent megoldást, míg a SharePoint Server 2007

ennek szolgáltatásaira építve, nagyvállalati környezetben is megállja a helyét. A 8 Microsoft Office SharePoint Server 2007 rövidítése 33 kettő közötti különbség nem csak a beépített megoldások mennyiségében jelentkezik, hanem az anyagi ráfordításban is, ezért beruházás előtt célszerű behatóan megvizsgálni, mely opciókra van feltétlenül szükség, s melyeket lehet nélkülözni. A továbbiakban az egyes változatok funkcionalitása kerül felsorolásra (egymásra épülve), majd ezek közül a dolgozat szempontjából lényeges szolgáltatások kerülnek bemutatásra. [8], [9] WSS 3.0 szolgáltatások:  dokumentumtárak  listák  subsite-ok (site-ban létrehozott másik site)  workflow-támogatás (munkafolyamatok)  alkalmazás template-k  Office 2007 integráció  keresés site-on belül  blog9, wiki10 MOSS 2007 Standard szolgáltatások:  Enterprise Search  Web Content Management – tartalom

menedzsment  továbbfejlesztett workflow-támogatás  My Site – saját oldal MOSS 2007 Enterprise szolgáltatások:  Excel Services (Excel Szolgáltatások)  InfoPath Services (InfoPath szolgáltatások)  Business Intelligence (Üzleti Intelligencia)  KPI Listák  Dokumentumközpont 9 A blog időrendben tárolt, fordított időrendben megjelenített cikkek sorozata. A kifejezés az angol weblog kifejezésből származik. 10 A wiki weboldalak gyűjteménye, ahol a felhasználók egy egyszerűsített leírónyelv segítségével hozhatnak létre vagy módosíthatnak elektronikus tartalmakat. 34  Site, Subsite A MOSS 2007-ben található tartalmak nagy része a böngészővel megtekinthető siteokon keresztül érhető el. A rendszer telepítése után előre definiált példányok állnak rendelkezésre, mint például Home, Document Center, News, Reports, stb. Az informatikai szakemberek és adminisztrátorok az egyes tevékenységi

körökhöz újabbakat hozhatnak létre a rendelkezésre álló – vagy korábban saját kezűleg megszerkesztett – site template-ek közül választva. A site-ok tetszőlegesen testre szabhatók, válogatni lehet a színvilágot és megjelenítést módosító témák, MasterPage11-k, és egyéb beállítások között. Az oldalakra a rendszer által felkínált, vagy saját magunk által elkészített WebPart12-ok helyezhetők el. Az adott site-on belüli jogosultságok igen nagy részletességgel testre szabhatóak, melyeket az oldalak és a rajtuk elhelyezett dinamikus felületi elemek alapbeállításként örökölnek.  Dokumentumtár A szervezeten belül minden dokumentum és tartalom egy központi helyen tárolható, strukturálható, így a felhasználók egységes módon navigálhatnak és kereshetik meg a számukra értékes információkat. Változatos rendezési és szűrési beállítások állnak rendelkezésre, melyekkel a rendszer által támogatott Word, Excel,

PowerPoint, InfoPath, stb., vagy egyéb típusú állományok kezelése gyorsítható meg.  Lista A SharePoint listák nem sokban térnek el a dokumentumtáraktól. A különbség abban áll, hogy nem fájlok, hanem felhasználó által létrehozott listaelemek kerülnek benne eltárolásra. Ezekhez különböző típusú attribútumok definiálhatók, hasonlóan egy adatbázishoz.  Enterprise Search A WSS 3.0 egyik hátránya, hogy keresési lehetőségei mindig az adott site-ra korlátozódnak. A MOSS 2007 bővített funkcionalitásának köszönhetően lehetőség van külső tartalmak keresésére és indexelésére, többek között weboldalak, más SharePoint site-ok, Active Directory, Exchange mappák, fájl megosztások és üzleti adatok között is. 11 A MasterPage egy ASP.NET technológia, ami lehetővé teszi, hogy a website-nak egységes kinézetet határozzunk meg azzal, hogy a változó tartalom köré mindig ugyanazt a keretet generálja. 12 A WebPart egy

dinamikus kontrol, mely tetszőlegesen helyezhető el az ASP.NET oldalakon Előnye, hogy az általa hordozott funkcionalitás fejlesztői munka nélkül hordozható az egyes lapok között. 35  Web Content Management. A SharePoint-ban a publikálás folyamat több lépcsőn keresztül zajlik. A szerkesztők számára tartalomtípustól függően különböző editáló-felületek állnak rendelkezésre. A munka során a felhasználó több vázlatot (draft) is elmenthet anélkül, hogy az kikerülne a nyilvános weboldalra. Abban az esetben, ha a szerkesztő úgy gondolja, hogy a tartalom elnyerte végleges formáját, elmenti fő (major) verzióként és ezzel a döntéshozóhoz kerül elbírálásra. A felettes megvizsgálja a végterméket és vagy visszaküldi módosításra mellékelve megjegyzéseit, vagy elfogadja, s ezzel megnyílik a lehetőség a fogalmazvány publikálására. A 2003-as verzióban a SharePoint mellett külön entitásként létezett a webes

tartalommenedzsment. A 2007-es kiadásban megtörtént az egyesítés, így a külső és belső publikálás egyetlen rendszer hatáskörébe került.  My Site – Saját oldal A MOSS 2007 My Site funkciója az íróasztal analógiájára, annak digitális megfelelőjeként lett megalkotva. A rendszer felhasználóinak rendelkezésére áll egy saját website, amit tetszésük szerint testre szabhatnak. Létrehozhatják saját oldalaikat, dokumentumtárakba tölthetik az irataikat, kijelzőket helyezhetnek el, stb. Lényegében minden művelet elvégezhető, amit a SharePoint webes felülete támogat.  Workflow támogatás A WSS 3.0 újdonságaként jelent meg a munkafolyamat-támogatás, mely a háttérben a dolgozat következő fejezetében ismertetett Windows Workflow Foundation szolgáltatásait veszi igénybe. A workflow-k használatával automatizmusok építhetők be az oldalakba, listákba, dokumentumtárakba. A MOSS 2007 a felhasználók rendelkezésére

bocsájt olyan „out-of-thebox” munkafolyamatokat, melyek az alapvető igényeket kielégítik Megtalálható köztük többek között jóváhagyási, többszörös jóváhagyási és véleményezési workflow, melyek néhány kattintással egy kiválasztott dokumentumhoz rendelhetők. A definiált munkafolyamatpéldányok többféle opcióval is indíthatók:  manuálisan  automatikusan, valahányszor új elem jön létre az adott listában / dokumentumtárban  automatikusan, valahányszor megváltozik egy elem az adott listában / dokumentumtárban 36 A SharePoint támogatja a szekvenciális13, illetve az ennél általánosabb, bővített lehetőségekkel rendelkező state machine (állapotgép) workflow14-k futtatását. Előbbihez elegendő a SharePoint Designer15 eszközkészlete, melynek előnye, hogy a folyamatot a tervezést követően magától adott listához kapcsolja, hátránya, hogy ezt az újrafelhasználhatóság rovására teszi. Utóbbi

létrehozásához Visual Studio 2008-ra van szükség, mely beépítetten támogatja a SharePoint workflow-k kezelését és debuggolását, elősegítve a hibamentes folyamatok definiálását. A Designer-ben való tervezéshez képest jóval komplexebb feladatról van szó, ebből kifolyólag nagyobb erőfeszítést és több erőforrást igényel. A nagyobb szakértelem-szükséglet természetesen megtérül, ugyanis a definiált workflow-k újrafelhasználhatóak, bármely listához / dokumentumtárhoz hozzárendelhetők, illetve a fejlesztő maga is gyárthat olyan építőkockákat, amelyek állomásaként szolgálnak egy magasabb szinten megtervezett munkafolyamatnak.  InfoPath Form Services A kezdő internet-használók is hamar szembesülnek a ténnyel, hogy az online szolgáltatások igénybevétele előtt egy regisztrációs procedúrán kell átesni. Az adatokat minden esetben online űrlapok formájában kéri be a rendszer, melyeket többnyire PHP, JSP,

ASP.NET, illetve egyéb szerver-oldali szoftverkomponens dolgoz fel. A Microsoft Office termékcsomagban található InfoPath16 alkalmazással való együttműködés már a MOSS 2003-ban is tetten érhető volt. Az InfoPath Form Services létrehozására a vastagkliens korlátozásai motiválták a Microsoft fejlesztőit. A MOSS 2007-ben az elkészített űrlapsablonok a Form Services aktiválását követően böngészőben is kitölthetők, nem szükséges bonyolult webes alkalmazások fejlesztésére erőforrást áldozni. A SharePoint-al integrált, platform-független, online adatbevitel lehetősége bizonyos területeken komoly konkurenciát jelent a többi technológia számára. 13 A szekvenciális workflow-ban a feltétel-akció párok egymásutánja határozza meg a végrehajtandó feladatot 14 A state machine workflow állapotok egymásutánjával és állapotátmenetek sorozatával írható le, s az állapotváltozásokat a definiált állapotátmenetek mentén

bekövetkező események határozzák meg. 15 A SharePoint Designer 2007 egy sokoldalú tervező alkalmazás, mely többek között SharePoint oldalak létrehozására, szerkesztésére, illetve workflow-k definiálására alkalmas 16 Az InfoPath 2007 segítségével az informatikában az átlagosnál jártasabb felhasználók professzionális fejlesztői munka nélkül tudnak űrlap-sablonokat összeállítani. A megszokott Windows kontrolok felhelyezésével és adatkapcsolatok létrehozásával, bekötésével komplex funkcionalitás valósítható meg. A sablon alapján adatokkal feltöltött űrlapot reprezentáló XML állományok természetesen csak olyan számítógépen tekinthetők meg, melyeken szintén telepítve van az InfoPath megfelelő verziója. 37  Blog, Wiki Az internetes naplók (blog) és tudástárak (wiki) a világháló legnépszerűbb felhasználási formái közé tartoznak. Elterjedésükkel világméretű közösségek, öt kontinensen átívelő,

kooperációt és kommunikációt megvalósító csoportok jöttek létre, ledöntve a távolság szabta fizikai korlátokat. A blog a SharePoint világában site template-ként (webhelysablonként) jelenik meg, amely speciális listákkal valósítja meg a blog-funkciókat. A MOSS 2007 többi szolgáltatásához hasonlóan egyszerűen oszthatók a felhasználói jogok, így a klasszikus egyszemélyes blog helyett valóban csoportos tartalomépítési lehetőségeket hordozhat. Jól konfigurálható, hogy kik olvashatják és kik szerkeszthetik a bejegyzéseket, sőt, ha igény van moderált bejegyzések megjelenítésére, jóváhagyási lánc definiálására is van lehetőség. A wiki-k többnyire közösségi portálok részeként érhetők el, de csoportmunkára gyakorolt pozitív hatásai miatt vállalati intraneten belül is egyre gyakrabban találkozni velük, például a céges tudásmenedzsment informatikai hátterének megvalósításánál. A SharePoint Wiki egy speciális

egyszintű, mappák nélküli könyvtár, melynek elemei a wiki-lapok. Az oldalak valójában ASPX17-fájlok, melyek egyrészt közvetlen URL18-el, másrészt WikiWord19 szintakszissal is meghivatkozhatók. A Wiki library úgy épül fel, mint egy dokumentumtár. Sorai az egyes oldalak, oszlopai alapértelmezésben a téma megnevezése és tartalma. Természetesen további attribútumokkal is bővíthető a táblázat, ha az üzleti igény úgy kívánja. 4.23 A SharePoint üzleti intelligencia megoldásai A bennünket körülvevő adatmennyiség szinte elképzelhetetlen mértékben növekszik. A modern adatbázis-kezelő rendszerek már képesek megbirkózni az adatgyűjtés és tárolás feladatával, sőt az előrejelzések szerint az igények fejlődésével is lépést tudnak tartani. Szinte fel sem merül az a kérdés, hogy miért érdemes megőrizni a folyamatosan gyűlő adatokat, annyira magától értetődő mindenki számára, hogy az egyre szélesebbre duzzadó adatfolyam

hatalmas mennyiségű értékes információt rejt. A kérdés ma már inkább az, hogy miképpen lehet hozzáférni az adatbázisokban rejtőzködő információs kincshez. 17 Az ASP.NET oldalak megjelenítése ASPX kiterjesztésű fájlok segítségével történik 18 URL: Uniform Resource Locator, más néven webcím, mely az Interneten megtalálható bizonyos erőforrások (képek, szövegek) szabványosított címe. 19 A WikiWord két vagy több szóból álló, összeillesztett kifejezés, mellyel a cikk témakörét határozhatjuk meg. Leegyszerűsíti a különböző tartalmak közötti hivatkozásokat, ugyanis nem kell tudni a linkelni kívánt topic url-jét, csupán témáját, mivel a WikiWord hiperhivatkozásként funkcionál. Például: YearTwoThousand, WebHome. 38 Ma és valószínűleg a jövőben is emberek döntései formálják a világot. Az emberek korlátozott adatbefogadó-képessége és a hatalmas mennyiségű adat közötti rést úgynevezett üzleti

intelligencia eszközök és megoldások töltik be, amelyek az adatokból értékelhető információkat hoznak létre, melyek már tudássá szervezhetők. Az üzleti intelligencia az angol „business intelligence” szó szerinti fordítása. A magyar változat talán kicsit megtévesztő, hiszen nyelvünkben az intelligencia értelmi felfogóképességet, műveltséget jelent, míg az angolban van egy másik értelme is: hírszerzés. Az üzleti intelligencia valójában üzleti hírszerzést jelöl: egy vállalat saját adatainak, illetve a nyilvánosan hozzáférhető forrásoknak tudatos és szervezett gyűjtése, rendszerezése, majd erre alapozva lényeges üzleti relevanciával bíró információk szintetizálása és eljuttatása a vállalati döntéshozók, információ-fogyasztók számára. A SharePoint Server 2007 Enterprise kiadása magában foglalja azokat a funkciókat, melyekkel a cég vezetői számára webes felületen keresztül prezentálhatók az adatokból

nyert összegzett információk. A Report Center elnevezésű site template és az Excel Services segítségével kielégítő minőségű üzleti intelligencia megoldás állítható elő, növelve a céges portálrendszer szolgáltatásainak körét. [10], [11], [12], [13], [14]  Excel Services Elmondhatjuk, hogy az adatok összegzésével foglalkozó szakemberek leginkább kedvelt szoftverei közé tartozik a Microsoft Excel 2007, mivel minden olyan funkció megtalálható benne, mellyel táblázatokat, grafikonokat, és egyéb, adott témakörben szükséges kimutatásokat lehet készíteni. Bizonyos keretek között ezen a szinten is jól alkalmazható a szoftver, ám messze nem használja ki lehetőségeit, különösképpen ami a csoportos online felhasználást illeti. A SharePoint Server 2007 lehetővé teszi, hogy úgy őrizzük meg az Excel használatának előnyeit, hogy az adatok webes publikálása is hasonlóan egyszerű feladat legyen az átlagfelhasználók

számára is. Nincs szükség üzemeltetőkre vagy fejlesztőkre ahhoz, hogy a vállalati szakértők (pl. banki szakemberek) által létrehozott tartalom publikusan is megjelenhessen. Ugyanakkor a paraméterek bekérése és az adatok egy részének megjelenítése nem jelenti a háttérben lévő üzleti logika felfedését, rejtve marad a nyilvánosság elől. Az Excel Services a MOSS 2007 újdonsága, mely kibővíti az Excel 2007 felhasználásának lehetőségeit az adatok széleskörű megosztásával, továbbfejlesztett menedzselhetőséggel, biztonsági megoldásokkal, a munkalapok skálázható szerveroldali újrafeldolgozásával és interaktív webes felületen történő megjelenítésével. Az Excel állományokhoz való hozzáférés nem csak böngészőn keresztül, de programozott Web service 39 API20-n keresztül is megoldott, amit fejlesztők használhatnak komplex, szaktudást igénylő logikák implementálásához. A továbbiakban az ebben a szakaszban

említett jellemzők és szolgáltatások bemutatása következik. Az Excel Services architektúrája Az Excel Services az alábbi három alkotóelemből épül fel:  Excel Calculation Services Feladata a munkalapok betöltése, számítások elvégzése, külső adatkapcsolatokból származó adatok frissítése és a felhasználó interaktivitását biztosító session menedzselése  Excel Web Access Ez a komponens készíti el a Calculation Services által átadott értékek alapján a HTML kimenetet, mely a felhasználók számára lehetővé teszi a böngészőből történő interaktív munkavégzést. A többi SharePoint kontrolhoz hasonlóan WebPart technológiával készült, tehát bármely oldalra felhelyezhető.  Excel Web Services Az elnevezéssel analóg módon ez egy webszolgáltatás, melyet a Windows SharePoint Services-en keresztül érnek el a fejlesztők. A programozott hozzáférésnek köszönhetően külső alkalmazásból is elérhetőek

és módosíthatóak a munkalapok anélkül, hogy újra létre kellene hozni a működésüket leíró üzleti logikát. 12. ábra Az Excel Services felépítése 20 Application Programming Interface, alkalmazásprogramozási interfész: egy program vagy rendszerprogram azon eljárásainak és azok használatának dokumentációja, amelyet más programok felhasználhatnak. 40 Ahogy az ábrán is látható, a három komponens két csoportba rendezhető: az Excel Web Access és az Excel Web Services a Web Front End-en, azaz a megjelenítési oldalon foglalnak helyet, míg az Excel Calculation Services az alkalmazásszerveren fut. A legegyszerűbb esetben mindkét réteg ugyanazon a fizikai szerveren található, de teljesítménynövelés esetén több kiszolgáló is megoszthatja a működéssel kapcsolatos feladatokat. Az Excel Web Access WebPart A technológia három fő alkotóeleme közül ez felelős a végfelhasználói interakció gördülékenységének

biztosításáért. Megjelenését három opció közül lehet kiválasztani:  Full Toolbar A munkalap manipulálásához elérhető össze funkciót felkínálja.  Summary Toolbar A Full Toolbar lehetőségeinek egy részhalmazát teszi elérhetővé, a többi, mint például a Frissítés, el vannak rejtve a felhasználó elő  Navigation Only A munkalappal elvégezhető interakciókat minimalizálja, csak a megtekintéshez feltétlenül szükséges opciókat kínálja fel. Előfordulhat, hogy az Excel dokumentum tartalma valamely logika által vezérelve felhasználótól függően más és más. A bejelentkezési információk alapján a szerver rendelkezésére áll a login ID, amit paraméterként ad át a munkalapnak, ami az adatok prezentálása előtt végrehajtja a szükséges szűrési eljárásokat. Az Excel Services biztonsága Az Excel Services jogosultsági és hozzáférési mechanizmusa a SharePoint Server 2007 biztonsági rendszerén keresztül valósul

meg. A felhasználók munkalapokkal kapcsolatos tevékenységének körét a dokumentum tulajdonosa határozza meg, mely többek közt lehet:  Olvasási jog (tartalom megtekintése)  Szerkesztési jog (tartalom megtekintése, megváltoztatása, kiegészítése)  Adminisztrátori jog (teljes felhatalmazás) A szerzői jogok és a hamisítás elkerülése végett a dokumentum tulajdonosának lehetősége van az egyébként alapértelmezett letöltési opció tiltására is. A láthatóság részletekbe menő konfigurálása létfontosságú abban az esetben, ha kritikus adatok közléséről van szó. A webes felhasználók számára a munkalapnak csupán memóriabeli példánya áll rendelkezésre, melyben értékek sorozata szerepel, a forrásként szolgáló üzleti logika és adatforrás-kapcsolatok mindvégig rejtve maradnak. 41 Mivel az Excel dokumentumok érzékeny információkat, sőt, akár veszélyes tartalmakat is hordozhatnak, elkerülhetetlen az

engedélyezett források meghatározása. Beállítható, hogy az Excel Services csak az Adminisztrátor által megadott helyeken, úgynevezett Trusted File Location-ökön található munkalapokat dolgozzon fel, melyek lehetnek SharePoint 21 dokumentumtárak, UNC illetve HTTP útvonalak. A rendszergazda felelőssége meghatározni, hogy mely felhasználóknak van jogosultsága tartalmat elhelyezni ezek valamelyikére. Kapcsolódás külső adatforrásokhoz Az Excel Services kiemelkedő szerepet játszik a SharePoint által nyújtott üzleti intelligencia megoldásokban, ezért elengedhetetlen, hogy a belső adathalmazon kívül számos külső forrással is képes legyen kapcsolatot teremteni. A munkalapokat átlagfelhasználók is összekapcsolhatják élő információforrásokkal, szabadon válogatva az Excel 2007-ben elérhető típusok közül, mint például:  Microsoft SQL Server Analysis Services  Microsoft SQL Server relációs adatbázisok  ODBC 

OLEDB Az Excel Services önmagában is rendkívül hasznos funkciókkal igyekszik megkönnyíteni a felhasználók munkáját, de valódi ereje a Report Center szolgáltatásain keresztül mutatkozik meg.  Report Center A Report Center egy SharePoint site template, melyet riportok és kimutatások megjelenítésére optimalizáltak. A MOSS 2007 Enterprise telepítésekor automatikusan létrehoz egyet a rendszer, melyet böngészve megismerhetők a főbb építőelemek: Report-ok, Dashboardok, KPI listák, Data Connection Library-k, Report Calendar. A komponensek WebPart technológiával lettek megvalósítva, ebből kifolyólag a vállalat belső működéséről képet adó látványos felületek létrehozásával átlagfelhasználók is könnyedén megbirkóznak. Data Connection Library Az Excel Services-t bemutató fejezet említést tett külső adatkapcsolatokról, melyek segítségével adatforrások széles köréből nyerhető ki a riport számára releváns információ.

A kimutatásokat készítő felhasználók minden egyes alkalommal akár manuálisan is létrehozhatnak 21 Universal Naming Convention: a Windows operációs rendszer formátuma, amivel erőforrások, fájlok elhelyezkedése határozható meg a helyi hálózaton. Pl: \szervernévfájlnévxls 42 kapcsolatokat, de sokkal hatékonyabbá teszi a munkát, ha elegendő az előre definiáltak közül válogatni. A megoldást a Data Connection Library-k, azaz adatkapcsolatokat tartalmazó könyvtárak jelentik, melyek kialakítása és menedzselése a rendszer adminisztrátorának felelőssége. A DCL-ek Office Data Connection (ODC) fájlokat tartalmaznak, melyek a kapcsolat részleteiről szolgáltatnak információkat az alkalmazások számára. Az Excel Services biztonságával foglalkozó részben esett említés a Trusted File Location jellemzőről, mely garantálja az Excel állományok megbízhatóságát. Mivel nem csak maguk a fájlok, hanem a külső kapcsolatok is

eredményezhetnek hozzáférést érzékeny információkhoz, megkövetelhető, hogy csak a Trusted Data Connection Library22-k ODC állományai funkcionálhassanak aktív forrásként. Az említett két megkötés segítségével az adathozzáférés teljes ellenőrzésére és kézbentartására nyílik lehetőség. KPI (Key Performance Indicator) listák A KPI-k olyan webes kijelzők, melyek bizonyos folyamatoknak az elérendő céltól való távolságát kommunikálják a felhasználók számára. Egy kereskedelemből vett példa jól szemléltetheti alkalmazási körét: egy bolt napi átlagos bevételét szeretnénk követni a hónap elejétől a végéig. Három mérföldkövet tűzünk ki: 300000 Ft felett kitűnő, 200000 és 300000 között megfelelő, 200000 alatt pedig gyenge. Attól függően, hogy a nap végén megállapított hozam a hónap eleje óta eltelt napokéival átlagolva melyik intervallumba esik, úgy jelenik meg a numerikus érték és a grafika a kijelzőn.

A KPI listák négyféle adatforrásból nyelhetnek információkat:  SharePoint listából  Excel munkalapról  Microsoft SQL Server Analysis Services-ből  Manuálisan beírt, statikus adatokból 13. ábra KPI lista példa Az üzleti igénynek megfelelően különböző indikátorok hozhatóak létre, melyek hála a hordozhatóságnak, a vállalat SharePoint portálján bárhol megjeleníthetők. 22 Megbízható kapcsolatfájlokat tartalmazó könyvtár 43 Reports Library A Reports Library-ben vannak felhalmozva a későbbiekben tárgyalt dashboard-ok, és az Excel Services-el HTML formátumban megjelenített riportok. A dokumentumtárakhoz hasonlóan itt is definiálhatók nézetek, oszlopok plusz információt hordozó attribútumokkal, és megadható, hogy a rendszer mely felhasználóinak van joga megtekinteni az egyes kimutatásokat. Nem kell tehát csoportonként külön könyvtárat létrehozni, elegendő megtenni a szükséges beállításokat és a

szervezet minden tagja ugyanazt látja, „más szemüvegen keresztül”. Dashboard A fentiekben ismertetett komponensek egy-egy szigetmegoldást nyújtottak a mérőszámok, riportok, és grafikonok által reprezentált komplex vállalati folyamatok megjelenítésére. A SharePoint Server 2007 a Dashboard által teszi lehetővé, hogy a felhasználók a weboldalon elhelyezett, eltérő funkcionalitású WebPart-olkon keresztül értesüljenek a szervezet működésének különböző aspektusairól. 14. ábra SharePoint Dashboard minta Az ábrán látható, hogy egymás mellett foglal helyet a KPI lista, és két Excel Web Access WebPart, melyek mindegyike valamilyen, a Data Connection Library-ben tárolt 44 megbízható kapcsolaton keresztül gyűjti be a megjelenítendő információhoz szükséges adatokat. Előfordulhat, hogy a kijelzőket valamiféle szűrési mechanizmus által dinamikusan konfigurálhatóvá kell tenni, például a megadott év alapján kell levégezni

a számításokat. Ebben az esetben hasznos a Filter WebPart, mely összeköthető az oldalon található többi dinamikus kontrollal és meghatározható, melyik szabad paraméterük számára szolgáltasson felhasználó által kiválasztott értékeket. A Dashboard számos kényelmi funkcióval és beállítással rendelkezik, de ezek mindegyikének kifejtése nem tartozik a dolgozat célkitűzései közé. Az egyik legfigyelemreméltóbb opció az automatikus frissítés, mely tovább vékonyítja a határvonalat a webes és egy esetleges vastagkliens megoldás között. Az oldalon elhelyezett dinamikus kontroloknál beállítható, hogy megadott időközönként kérdezzék le újra az adatokat, s ezzel a felhasználó számára releváns információknak mindig a legfrissebb verziója áll rendelkezésre. A fejezetben bemutatásra kerültek a SharePoint Server 2007 azon funkciói, melyek alapján kijelenthető, hogy megfelelő alternatívát kínál a csoportmunkát,

munkafolyamatokat és üzleti intelligenciát előnyben részesítő vállalatok számára. A rendszer webes technológiákra épülő architektúrája és a dinamikus kontrolok által nyújtott rugalmasság egy versenyképes, felhasználói szempontból platform-független rendelkezésére. 45 megoldást bocsájt az ipari szereplők 4.3 .NET Workflow Foundation A nagyvállalatok többségére jellemző, hogy működésüket egyének vagy csoportok által egymás után elvégzett műveletek sorozata határozza meg, melyet munkafolyamatnak, angolul workflow-nak nevezünk. A kor követelményeinek megfelelően ezeket a procedúrákat szoftveres támogatással teszik hatékonyabbá, legyen szó automatizált, vagy manuális beavatkozást igénylő eljárásokról. Az utóbbi, gyakoribb esetben az emberi erőforrás felelőssége a folyamat inicializálása, az entitások életciklusának felügyelete és a váratlan események körültekintő kezelése. Mindkét változat

esetén definiálható lépések olyan diszkrét sorozata, mely meghatározza az ember és a szoftver tevékenységét a workflow-ban. A procedúra leírásának elkészültével elkészíthető az alkalmazás, mely informatikai hátteret biztosít az üzleti folyamatok gördülékeny lefutásának. A munkafolyamatok szoftveres úton történő megvalósítása koránt sem triviális feladat. Egyes eljárások időtartama órákban, napokban, hetekben mérhető, mialatt folyamatosan rendelkezésre kell állnia az állapotát meghatározó információknak. Előfordulhat, hogy végrehajtás közben más alkalmazásokkal is kommunikálni kell, esetleg emberi beavatkozás válik szükségessé. Az is megtörténhet, hogy már több munkafolyamat-példány megkezdte éles működését, amikor kiderül, hogy módosítani kell az eljárás definícióján, mindezt anélkül, hogy a létezők megszakadnának. A Microsoft a NET keretrendszer 30 és 35 verziójában megtalálható Workflow

Foundation létrehozásával tett lépéseket a fenti követelmények teljesítésének érdekében. [15] 4.31 A Workflow Foundation szolgáltatásai A Windows Workflow Foundation egy munkafolyamatok definiálását, végrehajtását és menedzselését lehetővé tévő technológia. A többi programhoz hasonlóan különféle feladatok megoldását végzi, de van néhány fontos tulajdonsága, ami megkülönbözteti a többi alkalmazástól:  az adatok perzisztens tárban23 történő elhelyezésével képes hosszú lefutású folyamatok kezelésére  a folyamatpéldányok futás közben, dinamikusan módosíthatók  a workflow-k létrehozása a deklaratív szemléletet erősíti, hiszen előre elkészített activity-ket kell összekapcsolni szemben az imperatív, sorról sorra történő programozással 23 Az állapotinformációk nem tarthatók napokig, hetekig az operatív memóriában, ezért egy bizonyos idő eltelte után elmentésre kerülnek a merevlemezre,

például egy SQL Server adatbázisba. Amikor újra aktivizálódik a folyamat, innen történik a visszatöltés. 46  lehetőséget biztosít kódtól független business rule-ok (üzleti szabályok) definiálására, melyeket később könnyen módosíthatunk az alkalmazás újraindítása vagy a rendszer bonyolult konfigurálása nélkül A WF a .NET keretrendszer részeként számos területen kínál megoldásokat, melyek közül a legfontosabbak:  általános workflow-technológia a Windows operációs rendszer számára  keretrendszer biztosítása a különböző, munkafolyamatokkal operáló alkalmazás számára  rendszerszintű és emberi beavatkozást igénylő workflow-k egységesítése  A WF, mint a Windows általános workflow-motorja Körültekintve a piacon elmondható, számos Microsoft és egyéb szoftvercég által készített Windows alkalmazás készült, ami rendelkezik valamiféle munkafolyamat támogatással. Elegendő, ha

csak az MS palettáját vesszük szemügyre: a BizTalk Server és az Exchange Server is profitál a workflow-rendszerek iránti keresletből. A technológia népszerűsége alátámasztja hasznosságát, de ugyanazon a platformon létező több eltérő megvalósítás nem szolgálja sem a felhasználók, sem a fejlesztők érdekeit. A Windows Workflow Foundation célja, hogy hasonlóan a népszerű fejlesztői komponensekhez, a Windows-platform részeként minden alkalmazás számára elérhetővé váljon. 15. ábra A WF elhelyezkedése a Windows platformon Az ábrán látható, hogy a WF szerver és kliens operációs rendszereken is elérhető, s a Microsofton kívül független külső fejlesztők (ISV – independent software vendor) és 47 végfelhasználók is hasznát vehetik alkalmazásaikban. A szoftveróriás célja, hogy a Windows platformra készített rendszerek a Workflow Foundation segítségével valósítsák meg munkafolyamataikat. Az előző fejezetben

ismertetett SharePoint Server 2007 és a következő generációs BizTalk Server már a WF-en keresztül implementálják workflow-megoldásaikat. A Workflow Foundation melletti elkötelezettség előtt fontos megérteni és felismerni a tényt, hogy a WF egy keretrendszer, nem pedig egy végfelhasználók számára készült intelligens tervezőeszköz. Nem tartalmaz teljes körű felügyeleti és menedzsment eszközöket, amikkel nyomon követhetők és replikálhatók az egyes folyamatok. Nem célja egy komplex munkafolyamat-kezelő rendszer kialakítása, inkább a workflow-technológiát alkalmazásaikban felhasználni kívánó fejlesztők munkájának hatékonyabbá tételét helyezi előtérbe.  Általános keretrendszer workflow alkalmazások számára A Windows platform általános workflow technológiáját megtervezni és elkészíteni nem triviális feladat. A korábban elkészült megoldások egyike sem alkalmas erre, mert mindegyik saját megközelítést alkalmaz. A

leggyakoribb esetben adott egy nyelv és egy grafikus tervező eszköz, amivel folyamatokat lehet definiálni, de nem tartalmaznak eszközkészletet univerzális problémák megoldására. A Workflow Foundation szakít a hagyományokkal, és egy általános keretrendszert bocsájt a fejlesztők rendelkezésére. A WF-ben egy munkafolyamat activity24-k sorozatával definiálható. Számos általános célú aktivitás áll rendelkezésre, melyek között megtalálható a klasszikus elágazás (if/else) és a ciklus (while) modellje is. A keretrendszer által felkínált activity-k kellően rugalmasak a széles problémakörben való felhasználásra, mégis szükség lehet saját, alkalmazás-specifikus építőelemek készítésére. Jó példa erre a Windows SharePoint Services, mely külön activity-vel rendelkezik task-ok létrehozására. A WSS-hez hasonlóan különböző területeken, például a gyógyászatban vagy a bankszakmában eltérő folyamatmodellek vannak, amikhez

egyedi aktivitások implementálása szükséges. A fejlesztői activity-k szabadon kombinálhatók beépített társaikkal, sőt, a programozók által legyártott típusok alacsonyabb absztrakciós szinten nemegyszer önmaguk is egy-egy procedúrát valósítanak meg. A Workflow Foundation munkafolyamatok készítéséhez a szintén Microsoft által szállított Visual Studio 2008 a legideálisabb megoldás. A beépített workflow-designer segítségével könnyedén elkészíthetők egyszerű lépéssorozatok, vagy a komplex folyamatok üzleti logikáját meghatározó váz. Az utóbbi kategória világít rá arra, hogy a WF miért inkább fejlesztőeszköz, mint problémakör-specifikus tervezőszoftver. Az alkotóelemeiben és 24 A WF esetén az activity a munkafolyamat egy építőkockáját jelenti. Lehet elemi művelet, például egy if/else elágazás, vagy önmaga is megvalósíthat egy egyedi folyamatot. 48 algoritmikusan összetett folyamatokat nem lehet grafikus

eszközökkel, programozás nélkül elkészíteni. Az egyéni programkód hozzáadásának támogatása végett szerepel a beépített activity-k között a Code Activity. Ez a kontrol biztosítja azt a fokú szabadságot és rugalmasságot, hogy az általánosított keretrendszer eszközeivel specializált alkalmazásokat lehessen készíteni. 16. ábra Visual Studio 2008 Workflow Designer működés közben A Workflow Designer kényelmi szolgáltatásai természetesen nem csak az olcsónak nem mondható Visual Studio 2008-ban használhatók. A külső szoftverfejlesztő cégek a keretrendszer alapjainak felhasználásával saját tervezőeszközt készíthetnek. Ennek előnye, hogy specializált activity-k, előre elkészített folyamatok és egy könnyen használható designer segítségével a fejlesztői tapasztalatokkal nem rendelkező egyén is összeállíthatja a maga workflow megoldásait. Az elkészült munkafolyamatok futtatására számos lehetőség kínálkozik.

Egyszerű konzolalkalmazásban, Windows Forms-al elkészített grafikus GUI25-ban, ASP.NET szerverprocesszben, vagy akár külső beszállító által tervezett szoftverkomponensben. Mindebből tisztán látszik a Microsoft az irányú törekvése, hogy a létrejött workflow-k bármely környezetben érvényesülni tudjanak. Függetlenül attól, hogy az alkalmazásgazdák és a 25 Graphical User Interface – Grafikus Felhasználói Felület 49 tervezőfelületek felhasználói élmény szempontjából különböznek, a munkafolyamatok működését mindvégig egy közös alap, a Windows Workflow Foundation keretrendszer fogja biztosítani.  Egységesített munkafolyamatok Az üzleti folyamatok többségében egyaránt szükséges az emberi és a számítógépes beavatkozás is. Az informatikai megvalósítás számára a kihívás a kettő eltérő működésében és kezelési módjában keresendő. A rendszerszintű munkafolyamatokról, vagy más néven

orkesztrációkról elmondható, hogy viselkedésük megjósolható és az esetek nagy részében ugyanaz a lefolyásuk. Egymással strukturált üzenetek, például XML dokumentumok formájában kommunikálnak, mely szoftveresen feldolgozható és értelmezhető. Az emberi beavatkozásokkal színesített workflow-k sokkal nagyobb rugalmasságot követelnek a rendszertől. Gyakran előfordul, hogy valamivel kapcsolatban megváltozik az álláspont, új ötletek születnek vagy folyamatokat kell azonnal megszüntetni, egyszóval sokkal dinamikusabb viselkedést írnak le, mint rendszerszintű társaik. Eseményvezérelt működésük következtében a végkimenetel előre nem megjósolható, a kommunikáció strukturálatlan üzenetek (dokumentumok, e-mailek) formájában történik. A Workflow Foundation célja egy olyan egységes munkafolyamat-platform prezentálása, mely mindkét irányvonal esetén jól használható alternatívákat képes felmutatni. 4.32 A Workflow Foundation

folyamatai  Szekvenciális munkafolyamat A szekvenciális munkafolyamatokat akkor érdemes alkalmazni, ha meghatározott feladatokat kell előre definiált sorrendben elvégezni. Tartalmazhatnak elágazásokat, ciklusokat, de mindig véges a végrehajtás módjainak halmaza. Utóbbi tulajdonságának következtében főleg rendszerfolyamatok és egyéb szoftverek által vezérelt workflow-k esetén tud érvényesülni. A keretrendszer számos előre elkészített activity-vel támogatja ezt a típust, melyek közül a legfontosabbak:  If/Else: elágazás, mely a feltételtől függően különböző útvonal-alternatívákat definiál  While: a feltétel teljesüléséig ismétli a blokkban található részfolyamatot  Sequence: a benne található aktivitásokat szigorúan egymás után hajtja végre  Parallel: két vagy több szekvenciát definiál, melyeket párhuzamosan kell végrehajtani. Csak akkor folytatódik a workflow, ha minden szál elérte

végállapotát. 50  Code: tetszőleges .NET kódot hajt végre, melyet a fejlesztő C# vagy VBNET nyelven ír meg  Compensation Handler: hibakezelést megvalósító komponens. Akkor hajtja végre a számára meghatározott lépéseket, ha a vizsgált blokkban hiba történik.  Listen: bizonyos esemény hatására aktivizálódik és futtatja le a számára előírt lépéssorozatot  Delay: meghatározott időre felfüggeszti a végrehajtást  CallExternalMethod: meghív egy, az alkalmazásban szereplő, de a workflow-n kívül eső függvényt  HandleExternalEvent: külső esemény hatására aktivizálódik és hajtja végre a lépéssorozatot  Invoke Workflow: egy másik munkafolyamat végrehajtását kezdeményezi  Invoke WebService: webszolgáltatás hívása  Transaction Scope: meghatározott aktivitások sorozatát egy atomi műveletbe sűríti és egy lépésként hajtja végre  Terminate: leállítja a munkafolyamat

működését A munkafolyamatok készítésében jártas szakemberek könnyen vonhatnak párhuzamot a Sequential Workflow és a Microsoft és IBM által korábban megalkotott BPEL (Business Process Execution Language) között. A két technológia közti átjárhatóság megoldott, így a WF folyamatok könnyedén exportálhatók BPEL be és viszont.  Állapotgép Állapotgép esetén az activity-k egy-egy állapotot valósítanak meg, melyek között események által kiváltott átmenetekkel lehet mozogni. Alkalmazása akkor szükségszerű, mikor a lépések sorrendje előre nem ismert, vagy annyi a lehetséges variáció, hogy szekvenciális munkafolyamatként való megvalósítása nem lenne praktikus. Az emberek munkáját irányító workflow pontosan ebbe a kategóriába esik. Lehetőséget biztosít minden állapot elérésére, egyes lépések kihagyására, vagy az egész folyamat leállítására bármely pillanatban. Az állapotgépek logikája hasonlít a szervezetek

üzleti folyamatainak modellezéséhez, ezért a fejlesztők és a vállalati szakemberek hatékonyan tudnak együttműködni. State Machine workflow-k készítésekor kibővül a másik típusnál megismert activity-k köre, és az alábbiak is elérhetővé válnak:  State: az állapotgép egy állapotát reprezentálja  EventDriven: bizonyos esemény hatására végrehajtásra kerülő activity-k sorozatát definiálja 51  SetState: megváltoztatja a folyamat állapotát  StateInitialization: activity-k sorozatát definiálja, melyet a megadott állapotba érkezéskor egyből végre kell hajtani  StateFinalization: az állapot elhagyásakor végrehajtandó lépéssorozatot határozza meg 4.33 A Windows Workflow Foundation és a SharePoint Server 2007 A dolgozat SharePoint Server-el foglalkozó fejezetében már volt szó a csoportmunka támogató rendszer munkafolyamatokkal kapcsolatos lehetőségeiről. Megállapításra került, hogy míg az üzleti

felhasználók inkább a SharePoint Designer-t használják egyszerű, szekvenciális procedúrák létrehozására, addig a fejlesztőknek a Workflow Foundation segítségével állapotgépek definiálására is van lehetőségük. Megvizsgálva egy dokumentum életciklusát, melynek állomásai többnyire emberi erőforrások, a humán interaktivitást igénylő folyamatok főleg az utóbbi kategóriából kerülnek ki. A workflow-val való együttműködés a portál jellegéből adódóan ASPX oldalakon keresztül zajlik. Ahhoz, hogy ne csak fejlesztők tudjanak ilyen felületeket létrehozni, lehetőség van a korábbiakban már szintén említett InfoPath 2007 segítségével megtervezni és a SharePoint-ba publikálni a kommunikációs interfészeket. A leírtakból látszik, hogy a Workflow Foundation minél több területen való szerepeltetése a szoftveróriás céljai között szerepel. A keretrendszer általános megvalósítása teszi lehetővé, hogy kellő mértékű

specializáció után olyan rendszerek működésének legyen meghatározó eleme, mint a MOSS 2007. 4.34 A Workflow Foundation összefoglalása Idővel minden, munkafolyamatok készítésében érdekelt szakember számára nyilvánvalóvá válik, hogy a workflow-k létrehozása megfelelő eszközök híján nehézkes feladat. A hosszú lefutású üzleti folyamatok, az ember természetéből fakadó dinamikus viselkedés és a további nem triviális igények kihívások elé állítják a fejlesztőket. A Workflow Foundation célja egy olyan általános keretrendszer megvalósítása, mely mindezen problémák hatékony és kevés erőfeszítést igénylő megoldását teszi lehetővé. Abban az esetben, ha a technológia széles körben elismertté és közkedveltté válik, a közeljövőben akár a Windows platform alapvető komponensei között lehet majd említeni. 52 5. Üzleti intelligenciát támogató rendszer kialakítása A fejezet célja, hogy a

megelőző szakaszokban ismertetett technológiák felhasználásával bemutassa egy csoportmunkát, munkafolyamatokat és üzleti intelligenciát támogató rendszer kialakításának folyamatát. A végtermékként előálló alkalmazás természetesen egyéni munka gyümölcse, de az egyes munkafázisok a Microsoft Solutions Framework csapatmodelljében kerülnek elhelyezésre. A leírás jellege vízesés-szerű projektszervezésre engedhet következtetni, de ez csak a dolgozat lineáris szerkezetének hatása. Az egymás utáni fázisokban bemutatott eredmények mindegyike egy-egy iterációs folyamat végterméke, mely egy részleteiben kidolgozott megoldás megszületését tette lehetővé. Tekintve, hogy egy mérnöki feladat gyakorlati megvalósításáról lesz szó, a marketinggel és értékesítéssel foglalkozó termékmenedzserek, és a kiszállítást végző üzemeltetés tevékenysége nem kerül bemutatásra. 5.1 Feladatspecifikáció,

követelmények megfogalmazása Az ügyfél érdeklődésének felkeltése és a közös együttműködésről történő tárgyalások után jelenthető ki, hogy sikeresen elindult a szoftverprojekt. Feltéve, hogy a megrendelő egy alkalmazásokat és rendszereket készítő informatikai céggel köt megállapodást, biztosra vehető, hogy nem egy általános, nyilvánosan megvásárolható készterméket szeretne magáénak tudni. Az tapasztalat azt mutatja, hogy három féle forgatókönyv figyelhető meg, ahol az ügyfél:  szolgáltatást vesz igénybe különösebb módosítások nélkül  létező rendszert vagy szolgáltatást vásárol, melyet saját igényeire kell testre szabni (új folyamatok, interfészek, adatmigráció)  egy még nem létező, de a szoftvercég profiljába illő alkalmazás elkészítésére nyújt be igényt. A második és harmadik eset igényel komoly erőforrásokat, ám hogy melyik többet, azt a feladat jellege határozza meg.

Számos esetben előfordult már, hogy a projekt vége felé közeledve derült ki, költséghatékonyabb lett volna egy új rendszert készíteni, mint kényszerű módosításokat eszközölni a meglévőben. A feladatspecifikáció és a követelmények meghatározása, elemzése a Programmenedzsment és a Felhasználói élményért felelős csoport hatáskörébe tartozik. Utóbbi igyekszik minél átfogóbban megérteni a felhasználó igényeit, elvárásait, előbbi pedig ez alapján megfogalmazza a követelményeket, garantálja teljesülésüket, vezeti a projektet. Ajánlott az Architektúrát tervező, az informatikai eszközök széles skáláját ismerő szakemberekkel is 53 egyeztetni arról, vannak-e technológiai akadályai a megbeszélteknek, s milyen becsült költségekkel jár a megvalósítás. 5.11 A feladat leírása Az állam tulajdonában lévő, közszolgálatot ellátó hivatalok a civil szférában elért sikereket látva egyre nyitottabbak a

központosított, csoportmunkát és munkafolyamatokat támogató informatikai rendszerekkel szemben. A diplomafeladatban egy képzeletbeli önkormányzat egyszerűsített kérvény-elbírálási és állapotfigyelő-értesítő rendszere lett megvalósítva, mely megfelelő hardvererőforrások rendelkezésre állása esetén ipari felhasználásra is alkalmas mind belföldi, mind nemzetközi viszonylatban. A rendszer lehetővé teszi, hogy az ügyintézők a beérkező kérvényeket megvizsgálják, ha kell, módosítsák, majd elküldjék jóváhagyásra. Az elbírálás során megtekinthető a dokumentum, majd elutasítható vagy jóváhagyható. A kiírt feladatokról természetesen minden érintett alkalmazott értesítést kap. A kérvények az állapotukon kívül más paraméterekkel is rendelkeznek, melyekből hasznos statisztikai és döntéshozáshoz szükséges információk szűrhetőek le. A részleg vezetője egy interaktív felületen keresztül kísérheti

figyelemmel a rendszer állapotát és napi illetve havi összegzéseket kap e-mail üzeneteken keresztül. Az aggregációk és jelentések készítéséért felelős automatizmusokat az adminisztrátor által menedzselt munkafolyamatok irányítják. Végrehajtás közben, szabadon állítható paraméterekkel zökkenőmentesen változtatható meg egy-egy processz viselkedése az aktuális kívánalmaknak megfelelően. A következő szakaszban e rövid leírás kifejtése következik, mely megfogalmazza az általános követelményeket, specifikálja a rendszer alkotóelemeit, entitásait és folyamatait. 5.12 A követelmények megfogalmazása, specifikáció  Általános elvárások A rendszernek integrálhatónak kell lennie a létező tartományba, hogy a szervezet alkalmazottainak adatai az Active Directory26 címtárszolgáltatásból elérhetőek legyenek. A felhasználók azonosítása is ezen keresztül történjen, ne legyen saját készítésű authentikációs

mechanizmus. 26 Az Active Directory a Microsoft Windows környezetben használatos címtárszolgáltatás. Fő célja a Windows operációs rendszert futtató számítógépek részére authentikációs és authorizációs szolgáltatások nyújtása, lehetővé téve a hálózat minden publikált erőforrásának (fájlok, megosztások, periféfiák, kapcsolatok, felhasználók, csoportok, stb.) központosított adminisztrálását, vagy decentralizált felügyeletét. 54 Az egyszerű frissíthetőség és a kliensek szempontjából operációsrendszer-független működés támogatása végett az alkalmazás web-felületen keresztül kell, hogy kínálja szolgáltatásait. Az oldalak megjelenése legyen könnyen változtatható mind a színvilág, mind a tartalmi elemek tekintetében. Utóbbi követelménynek egyértelmű következménye, hogy újrafelhasználható komponensek elhelyezésére legyen lehetőség. Támogatnia kell a hosszú lefutású folyamatokat. Nem elegendő

csupán az alkalmazások működését összehangolni, az emberi munkaerő bevonását igénylő procedúrák is legyenek automatizáltak. Mivel a kérvények dokumentumok formájában érkeznek, szükség van a Microsoft Office 2007 irodai programcsomaggal való együttműködésre. Az egyes fájloknak a felületről megnyithatónak kell lennie, illetve magából a szövegszerkesztő vagy táblázatkezelő alkalmazásból kell biztosítani mentést a rendszer adatbázisába. Az állományok nagy száma miatt gyors és széles körű keresésre van igény. Mivel a fájlok neve nem informál kellően azok információtartalmával kapcsolatban, ezért ki kell terjednie a dokumentumok szövegére is.  A kérvény állapotai, típusai A beérkező kérvények amellett, hogy szöveges dokumentumok, a keresés, szűrés és belső működés megkönnyítése végett leíró jellegű metaadatokat27 tartalmaznak. A két legfontosabb az állapot és a típus, melyek az alábbi értékeket

vehetik fel: Állapotok:  Jóváhagyásra vár  Jóváhagyás folyamatban  Jóváhagyva  Elutasítva  Lakástámogatás  Gázártámogatás  Szociális segély  Építkezési engedély  Rendezvény Típusok: 27 A metaadat adat az adatról. Ilyen a könyvtári nyilvántartó kártya, mely a könyvhöz tartozik és az alábbi információkat tartalmazza: író, cím, műfaj, tárolási hely, stb. 55  Felhasználói szerepkörök A rendszer érzékeny információkat kezel, ezért nagy hangsúlyt kell fektetni arra, kinek mihez van jogosultsága. Mappánként és dokumentumokként is meg kell tudni mondani, hogy a felhasználó csak olvashatja, vagy szerkesztheti is az adott tartalmat. Feldolgozók Feladatuk, hogy a Jóváhagyásra vár állapotú állományokat megnyissák, megvizsgálják és az esetleges módosítások elvégzése után elbírálásra továbbítsák azt. Elbírálók Az elbírálók felelőssége, hogy eldöntsék,

elfogadják az adott kérvényt vagy sem. Mindig csak a kérdéses dokumentumhoz van jogosultságuk, ezért elbírálás után már nem férhetnek hozzá. Menedzsment A menedzsment tagjai a feldolgozók és elbírálók felett állnak a hierarchiában. Ők hozzák a döntéseket, ezért valós idejű és időszakos jelentéseket kapnak a rendszer állapotáról. Az elbírálók által jóváhagyott vagy elutasított kérvények is hozzájuk érkeznek meg. Adminisztrátor Az adminisztrátor felügyeli a rendszer működését és orvosolja a felmerülő problémákat. Feladata ezen kívül a menedzsment számára riportokat előállító folyamatok konfigurálása, és az adatok megjelenítését végző felületek összeállítása. 56  A kérvény-jóváhagyási folyamat Az alábbi ábrán a kérvény-jóváhagyási folyamat vázlata látható. A nyilak melletti számok az események sorrendjét jelölik, melyek a kép alatti magyarázatban kerülnek kifejtésre. 17. ábra

Kérvény-jóváhagyási folyamat 1. A rendszeren kívülről - például az Internetről – megérkezik a kérvény és bekerül a közös tárhelyre, állapota: Jóváhagyásrva vár. Annak elkerülése érdekében, hogy többen kezdjenek el ugyanazon a dokumentumon dolgozni, mielőtt láthatóvá válik a felhasználók számára, speciális jogosultsági beállítások történnek rajta. A végeredmény az, hogy csak a kiválasztott illetékes feldolgozó képes megnyitni az állományt. 2. A rendszer értesítést küld a kijelölt személynek a kérvény érkezéséről. A felhasználó az üzenetben található linken keresztül elnavigál a keresett állományhoz, megvizsgálja, majd elindítja az elbírálási folyamatot. Ettől a pillanattól kezdve a dokumentum állapota: Jóváhagyás folyamatban. 3. Az elbíráló felhasználó üzenetet kap a rendszertől, hogy új feladat lett kiírva számára. Az előző pontban leírtakhoz hasonlóan hiperhivatkozás

segítségével éri el a jóváhagyásra elkészített felületet. Itt megtekintheti a kapcsolódó dokumentumot, s annak tartalmától függően jóváhagyhatja vagy elutasíthatja azt. A művelet végeztével a kérvény Jóváhagyva vagy Elutasítva állapotba kerül, s a feladatkiírás törlődik. 4. A dokumentum státuszának megváltozásával a feldolgozók és elbírálók elvesztik láthatósági jogosultságukat, a menedzsment tagjai pedig megkapják azt. Az eseményről a rendszer értesíti a vezetőket, akik a fentiekben már említett módon megtekinthetik az elbírált kérvényt. 57  A riportkészítő folyamat A kérvényezési folyamat optimalizálásának és a maximális áteresztő-képesség elérésének érdekében a belső működés rendszeres megfigyelése szükséges. Az egyre több helyen alkalmazott üzleti intelligencia eszközök segítségével mindez hatékonyan tehető meg. A rendszer aggregációs eljárásai a riportok és jelentések

megjelenítéséhez szükséges információkat gyűjtik össze a rendelkezésre álló adathalmazból. Az iratok állapota alapján olyan statisztikák készíthetőek, melyekből a vezető ki tudja következtetni, vajon elegendő-e az alkalmazott munkaerő, vagy szükség van további erőforrások bevonására. A kérvény-típusok napi vagy havi eloszlásából kiderül, mire van leginkább szüksége a szervezethez forduló ügyfeleknek, s ez alapján újra-priorizálhatók a feladatok. A rendszerben két automatizált folyamat végzi az adatok aggregálását és a riportok generálását, melyek működése az alábbi ábrán nyomon követhető: 18. ábra Riportgeneráló folyamatok 1. Az információgyűjtő automatizált folyamatokat az Adminisztrátor indítja el. A processzekhez tartozó szabad paraméterek segítségével lehetőség van a finomhangolásra és optimalizálásra, szükség esetén leállításra és újraindításra. 2. A folyamatok a kérvényeket

tartalmazó tárhoz fordulnak és lekérdezik a szükséges információkat. 58 3. /a. Az első eljárás az aktuális nap és hónap adataival kapcsolatos aggregációkat végzi el megadott időközönként. A számítások végeztével az alábbi információk állnak rendelkezésre:  a mai napon érkezett kérvények száma állapotok szerint csoportosítva  az aktuális hónapban érkezett kérvények száma állapotok szerint csoportosítva  a mai napon érkezett kérvények típusai százalékosan csoportosítva  az aktuális hónapban érkezett kérvények típusai százalékosan csoportosítva  a mai nap elbírált kérvények százalékos aránya az összes ma érkezetthez viszonyítva  jóváhagyásra váró iratok száma a mai napon Az adatok a riportokat kiszolgáló tárterületre kerülnek, ahonnan a megjelenítést végző modul felolvassa a kiszámított értékeket. /b. A második folyamat napi és havi szintű jelentéseket küld a

menedzsmentnek az aktuális nap és hónap végén. Előbbi esetben az aznap érkezett, jóváhagyott, elutasított és nem elbírált kérvények számáról informál, utóbbiban ugyanezt teszi, csak havi viszonylatban. 4. A menedzsment tagjai a rendszer webes felületén nyomon követik a kérvényezési folyamat során bekövetkező változásokat. A riportok külső beavatkozás nélkül, az adminisztrátor által beállított időközönként frissítik tartalmukat. A megvalósítandó rendszer követelményeinek, entitásainak és folyamatainak meghatározása egy általános képet ad a működéssel szemben támasztott elvárásokról. A specifikáció technológia-független mivolta biztosítja, hogy a következő fejezet kiemelt szereplői, az Architektek megtalálják az iparban fellelhető megoldások legoptimálisabb kombinációját. 59 5.2 Az architektúra tervezése A Microsoft Solutions Framework csapatmodelljében az Architekt feladata annak

megállapítása, hogy a specifikációnak megfelelő rendszer milyen szoftvermegoldások segítségével valósuljon meg. Vállalatonként eltérő, hogy mekkora hatáskörrel bír ennek végrehajtásában. Van, ahol a programmenedzsment munkájában is részt vesz, s az ügyféllel együttműködve módosításokat eszközöl a követelményeken, de az sem ritka, hogy részben fejlesztői erőforrásként funkcionál. A technológiák végleges kiválasztása előtt több esetet is megvizsgál. Ehhez kikéri az implementálást végző szakemberek tanácsát, hogy a megrendelő igényei az adott eszközök használatával teljesíthetők-e és milyen problémák adódhatnak. A döntés megszületése után a specifikáció alapján elkészíti a rendszertervet, mely a követelményekben megfogalmazott elvárásokat konkrét megoldásokkal teljesíti. 5.21 A platform kiválasztása A megrendelő által elképzelt rendszernek teljesen integrálódnia kell a szervezet már meglévő

informatikai infrastruktúrájába. A követelményekből kiderül, hogy a számítógépek hálózatba vannak kötve, ugyanannak a tartománynak a tagjai, s az alkalmazottak az Active Directory-ban tárolt felhasználónevükkel és jelszavukkal authentikálják magukat. Ebből következik, hogy a rendszert a Microsoft valamelyik szerver operációs rendszerén kell majd futtatni. A dolgozat a 2009-es évben íródik, ezért két OS28 közül is lehet választani. Az első a már hat éve rendelkezésre álló, kiforrott és sokak által ismert Windows Server 2003, mely a mai kiszolgálók hardverein megfelelő sebességet produkál. A második a Windows Server 2008, mely egyre nagyobb teret hódít, s új szolgáltatásainak köszönhetően fokozatosan kiszorítja elődjét. A specifikált rendszer mindkét esetben megvalósítható, de mivel a követelményekben nincs olyan tétel, mely a 2008-as változat használatát indokolná, ezért költséghatékonysági szempontból a

2003-as verzió az optimális választás. 28 OS: Operating System, magyarul: Operációs Rendszer 60 5.22 A felhasznált technológiák meghatározása A platform kellően behatárolja, hogy mely technológiák jelentenek életképes alternatívát a megvalósítás szempontjából. Az alábbi felsorolás a kiválasztott eszközöket mutatja be:  Microsoft .NET 35  Microsoft Office SharePoint Server 2007 Enterprise  Microsoft SQL Server 2005  Windows Workflow Foundation  E-mail és RSS Látható, hogy egyértelműen a Microsoft termékei dominálnak, ami természetesen nem jelenti azt, hogy nem létezik más megoldás. Anyagi, idő – és erőforrásbeli szempontok hatására teljesen más arculatot is ölthet a szoftver-architektúra. A következő szakaszok a technológiai döntések helyességét igyekeznek alátámasztani.  Microsoft .NET 35 – az alkalmazásplatform A szoftverek elkészítésének módját, működésének sebességét és

lehetőségeit a szakember hozzáértésén kívül az alkalmazásplatform és a programozási nyelv határozza meg. A követelményekből egyértelműen kiderül, hogy egy komplex funkcionalitással rendelkező webes portálrendszert kell kialakítani, mely Windows esetén a J2EE és az ASP.NET közötti választást jelenti. A J2EE egy széles körben elterjedt szerveroldali Java programozási platform, melynek specifikációját a Sun Microsystems készítette. Felépítése többrétegű, az egyes rétegekből több megoldás is létezik, ezért kellően rugalmasan alakítható ki a végleges architektúra. Az ASP.NET egy Microsoft által készített webalkalmazás-keretrendszer, mellyel website-ok és webszolgáltatások hozhatók létre. A 2002-ben megjelent NET Framework29 része, ezért bármely .NET által támogatott nyelv használható programozására Mindkét alkalmazásplatform esetén elkészíthető a követelményekben megfogalmazott rendszer, de a szükséges idő és

a fejlesztési költség az ASP.NET-el történő megvalósítást támasztja alá. Olyan kliens és szerveroldali, előre elkészített komponensekkel rendelkezik, melyek hatékonyan együttműködnek a Microsoft szoftvereivel, s több hónapos fejlesztési időt spórolnak meg. 29 A .NET Framework a Microsoft szoftveres keretrendszere, mely a vállalat több Windows operációs rendszerében is elérhető. Eszközök és megoldások egész sorát tartalmazza, mely jelentős fejlesztési időt spórol meg a programozóknak. Lényeges kiemelni, hogy a NET-ben írt alkalmazások futtatása egy, a keretrendszer részét képező virtuális gépben történik. 61  Microsoft Office SharePoint Server 2007 Enterprise – a portálrendszer A megrendelő elvárásainak megfelelő alkalmazás a fent ismertetett ASP.NET segítségével, az alapoktól elkezdve, saját koncepciók szerint reális időn belül elkészíthető. A testre szabható, moduláris oldalfelépítés, a

munkafolyamat-támogatás, az irodai programcsomaggal való együttműködés, az üzleti intelligencia támogatása és a teljes körű keresés mind megvalósíthatók, csak kellő számú szakemberre és tőkére van szükség. Ilyen komplexitású szoftverek esetén mindenképpen érdemes megvizsgálni informatikai cégek jó referenciákkal rendelkező megoldásait és azok alapjaira építkezni. Az Office SharePoint Server 2007 a Microsoft cég ASP.NET technológiára épülő portálrendszere. A dolgozat egy megelőző fejezetében részletesen ismertetésre kerültek szolgáltatásai, melyek megfelelnek a specifikációban leírtaknak, s egyből rendelkezésre állnak. Terjedése a civil – és közszférában is tetten érhető, mely egyértelműen alkalmazását indokolja. Az üzleti intelligencia és a széles körű keresési funkciók miatt a komolyabb eszközkészletű Enterprise változat lett kiválasztva.  Microsoft SQL Server 2005 – az adatbázisszerver A

modern informatikai rendszerekben az adattárolást adatbázisszerverek használatával oldják meg. Felmérve a kínálatot elmondható, hogy számos, egymással árban és tudásban versenyző megoldás lelhető fel a szoftverpiacon. Feltétlenül meg kell említeni az Oracle-t, a Microsoft SQL Server-t és a nyílt forráskódú MySQL-t. A köztük lévő különbség az általuk nyújtott szolgáltatásokban és az adatok kezelésének hatékonyságában rejlik, alkalmazásukról árukon kívül e szempontok alapján döntenek. Az előző szakaszban eldőlt, hogy esetünkben a SharePoint Server 2007 portálrendszerre kell építkezni, melynek természetes vonzata, hogy az alkalmazott adatbázisszerver a SharePoint által is használt Microsoft SQL Server 2005. Természetesen ismét felmerül a kérdés, érdemes-e az újabb, 2008-as verziót választani. Az üzleti intelligencia lehetőségek szempontjából mindenképp megfontolandó, hiszen fejlett riportkészítő és

megjelenítő felülettel rendelkezik, s letölthető add-in segítségével képes a SharePoint-al való együttműködésre. A döntésről feltétlenül egyeztetni kell az ügyféllel, hiszen amellett, hogy valóban hasznosak a 2008-as szerver említett szolgáltatásai, árban jóval meghaladja elődjét. A diplomafeladatban a költséghatékonyságot szem előtt tartva a 2005-ös verzió lett telepítve, mivel a követelményeknek megfelelő riportkészítő szolgáltatásokat a SharePoint Server 2007 eszközkészletével is meg lehet valósítani. 62  Windows Workflow Foundation – a folyamatmotor A rendszer automatizált és emberi beavatkozást igénylő folyamatainak irányításához szükség van egy olyan, a háttérben tevékenykedő szoftverre, melyet workflow-motor néven említenek. A Windows platformon elérhető az úgynevezett Windows Service is, mellyel megvalósítható ilyen jellegű funkcionalitás, de mivel nem munkafolyamatok vezérlésére lett

kitalálva és az emberi interakció is nehézkesen kezelhető le vele, használata ez esetben nem javasolt. Az iparban több megoldás is született, mind például az Apache ODE vagy a Java-alapú jBPM, de .NET környezetben egyértelműen a Windows Workflow Foundation a helyes választás. A Visual Studio 2008-ba integrált grafikus editor segítségével gyorsan elkészíthetők és egyből a SharePoint Server-re exportálhatók az elkészült munkafolyamatok.  E-mail és RSS – az üzenetkezelés A specifikációban leírtak szerint a rendszernek bizonyos eseményekről értesítenie kell a felhasználókat. A legáltalánosabb megoldás az, hogy minden esetben e-mail üzenetet küld, amit a címzett levelezőkliensébe érkezik. Amíg fiókonként 4-5 üzenetről van szó, elégséges megoldást nyújthat az elektronikus levél, ám e fölötti mennyiség gyakorlatilag ugyanolyan tartalmú üzenetekből feleslegesen terheli az e-mail szervert és tölti meg a postaládát.

Nagymértékű terhelés-csökkenés érhető el mind a hálózaton mind a kiszolgálókon, ha bizonyos üzenetek RSS hírcsatornákon keresztül érkeznek. A felhasználók így csak azokról az eseményekről kapnak értesítést, melyek valóban szignifikánsak teendőikkel kapcsolatban, nem kell e-mail konfigurációs beállításokat eszközölni a szerveren. Habár rengeteg ingyenes megoldás létezik, Microsoft Office 2007 irodai programcsomag használata esetén az Outlook alkalmazás által a technológia minden előnye kiaknázható. 63 5.23 A rendszer architektúrája A piac kínálatának felmérése és a felhasználandó szoftvereszközök kiválasztása után a követelményekben és folyamatleírásokban szereplő funkcionalitást megvalósító rendszerterv elkészítése következik. Az alábbi ábra az előző szakaszban bemutatott technológiák elhelyezkedését, a magyarázat pedig a megvalósításban betöltött szerepüket mutatja be. 19. ábra A

megvalósítandó rendszer-architektúra  Szerepkörök, jogosultságok A rendszer alapja a SharePoint Server 2007, mely lehetővé teszi, hogy a tartomány minden számítógépéről elérhető legyen a portálrendszer. A specifikációban meghatározott szerepkörök egy-egy felhasználót vagy felhasználói csoportot jelentenek különböző jogosultságokkal, melyekkel az egyes szolgáltatások elérhetőségének korlátozására nyílik lehetőség. Mindez a SharePoint portálon az eltérő szintet képviselő elemeken konfigurált hozzáférési szabályok segítségével történik. A feladat szempontjából a site-szintű, dokumentumtár-szintű és dokumentum-szintű jogosultságok mérvadók. Ezek beállítását és működését a megvalósítást tárgyaló fejezet mutatja be. 64  Kérvények tárolása, kezelése A kérvények tárolási helye egy Dokumentumtár, mely széleskörű szolgáltatásai révén teljesíti a specifikációban meghatározott

elvárásokat. A Microsoft szoftverek közötti interoperabilitást támasztja alá, hogy a SharePoint együttműködik az Office 2007 irodai programcsomag alkalmazásaival. A dokumentumtárból való fájlmegnyitás és az oda történő mentés az operációs rendszeren végzett műveletekhez hasonló módon hajtható végre. Előfordulhat, hogy szükséges a fájlok változásának követése A verziókezelés bekapcsolásával a kérvényen végzett módosítások a későbbiekben időrendben megtekinthetők. Az állományok nagy száma miatt a kérvények közötti keresés a bejegyzésekhez rendelt paraméterek segítségével is nehézkes és sok időt vesz igénybe. A SharePoint dokumentumtárak Full Text Search elnevezésű keresőszolgáltatása a fájl tartalmában is felkutatja az illeszkedő kifejezéseket, növelve a találatok pontosságát. A dokumentumok alapértelmezésként öröklik az őket tartalmazó tár jogosultsági beállításait, de egyéni láthatóság

beállítása esetén a kapcsolat megbontható. A feldolgozók, elbírálók és menedzserek ugyanahhoz a dokumentumtárhoz férnek hozzá, de csak azokat a kérvényeket érik el, amelyek elvégzendő feladataikat tekintve szignifikánsak számukra. A bejegyzések átláthatósága tovább finomítható az úgynevezett Nézetek alkalmazásával. A dokumentumokhoz tartozó paraméterek rendezése, szűrése és csoportosítása egy lépésben megoldható, így nem szükséges minden alkalommal egyesével beállítani őket.  Feladatok kiírása, végrehajtása A SharePoint listák egyik típusa a Task List, azaz feladatlista. A felhasználók és a rendszer is készíthet bejegyzéseket, megjelölve a végrehajtó személyt. A task-okra nem csak mint feladatra, hanem mint meghatározott állapotban lévő folyamatra is tekinthetünk, s ez a tulajdonság teszi alkalmassá a specifikációban leírt workflow-kal való együttműködésre. Az adminisztrátor ezen objektum

segítségével vezérli a jelentések létrehozását végző processzeket, illetve az elbíráló így kapja meg a számára kiírt jóváhagyási feladatokat. A dokumentumtárakkal kapcsolatban említett nézetekkel és jogosultságokkal kapcsolatos szolgáltatások erre a SharePoint elemre is érvényesek.  Kérvényezési és automatizált folyamatok A rendszerarchitektúrában található Workflow Foundation felelős a specifikáció által definiált munkafolyamatok futtatásáért. A SharePoint Server 2007-el való együttműködésének köszönhetően egyenesen a dokumentumtárak és task-listák elemeihez rendelhetők hozzá az egyes workflow-k. Mind az adminisztrátor által felügyelt automatizált, mind az emberi 65 beavatkozást igénylő kérvényezési procedúrákat képes menedzselni, utóbbi esetén fejlesztői eszközökkel testre szabható felületeken keresztül kommunikálva a felhasználókkal. A munkafolyamatok a hozzájuk rendelt entitás

paraméterein keresztül szabályozhatók, melynek mikéntjét a megvalósítást tárgyaló fejezet hivatott prezentálni.  Riportok, jelentések A menedzsment számára létfontosságú kimutatások a SharePoint Server 2007 üzleti intelligencia eszközeivel készíthetők el. A riportok webfelületen való megjelenítéséhez négy komponens együttműködésére van szükség. A jelentések adatforrása egy SQL Server 2005 adatbázis, melynek tábláiba a Workflow Foundation automatizált munkafolyamatai töltik be a számított értékeket. A frissítek gyakoriságát a task-listában található, futó workflow-hoz rendelt feladatelemen keresztül az adminisztrátor konfigurálja be. Az adatbázisba aggregált értékeket az Excel Services egy Excel munkalapon definiált adatkapcsolat-leírió komponensen keresztül bocsájtja a SharePoint Dashboard megjelenítést végző WebPart-jai rendelkezésére. A riportokat prezentáló web-felület periodikusan frissíti értékeit,

folyamatosan a legfrissebb információkkal ellátva a menedzsment tagjait. A workflow-k támogatják az offline jelentéseket is. Ebben az esetben az adatgyűjtést követően nem adatbázisba kerülnek az értékek, hanem az illetékesek kapják meg HTML e-mail üzenet formájában.  Értesítések Az előző alfejezet részletesen tárgyalta, hogy a gyakran érkező értesítéseket célszerű RSS hírcsatornákon fogadni. A SharePoint Server 2007 dokumentumtárai, feladatlistái és egyéb objektumai támogatják ezt az eljárást, mely a feldolgozókat, elbírálókat és menedzsereket tájékoztatja a számukra szignifikáns új kérvények vagy feladatok megjelenéséről. A rendszer lekérdezésekkel való túlterhelésének elkerülése érdekében beállítható, hogy a felhasználók milyen időközönként kérhetik a csatorna frissítését. A rendszer architektúrájának elkészítésével nem ért véget az Architect feladata, mert nyomon kell követnie a

fejlesztés lépéseit és ellenőrizni, minden a tervek szerint lett-e megvalósítva. A technológiák kiválasztásával és a komponensek közti meghatározásával kellő támpontot kaptak a fejlesztők az implementáció elkezdéséhez. 66 kapcsolat 5.3 A rendszer megvalósítása Az egymás mellé helyezett komponensekből álló rendszertervet a fejlesztők által elkészített szoftvermegoldások keltik életre. A munka elkezdése előtt megállapodnak, hogy milyen elveket követnek, mik a mindenkitől elvárt kódolási, hibakezelési és egyéb konvenciók. Az esetek többségében egy, a projekt profiljába illő módszertan alkalmazásfejlesztés-specifikus elemeit alkalmazzák igény szerint kisebb-nagyobb módosításokkal. A Windows platform és a .NET keretrendszer egyértelműen meghatározza a fejlesztőeszközt, ami a Microsoft Visual Studio 2008. A számos támogatott projekttípusnak és alkalmazássablonnak köszönhetően minden, a tervekben

szereplő komponens elkészítésére és tesztelésére alkalmas. A fejezet az egyes rendszerelemek implementálását, beállítását és összeállítását mutatja be, aminek végeredményeképpen előáll a specifikációban meghatározott működő megoldás. 5.31 A szerepkörök definiálása, jogosultságok meghatározása A SharePoint Server 2007 telepítésekor automatikusan felismeri azt a tartományt, melynek tagja a gazdaszámítógép. A domain-hez tartozó Active Directory felhasználói nem érik el közvetlenül a portálrendszert, engedélyezni kell számukra a belépést a címtárkiszolgálón beállított felhasználónevükkel és jelszavukkal. A jogosultságok kezelésének átláthatósága végett az egyes funkciókhoz való hozzáférést nem egyénre, hanem csoportra szabott engedélyek határozzák meg. Ez alól kivételt képez a rendszeradminisztrátor, aki számára az indítást követően bármi elérhető. Személye a SharePoint Central

Administration30 komponensében az Application Management/Site Collection Administrators szekcióban változtatható meg. 20. ábra SharePoint adminisztrátor beállítása A megvalósítandó rendszer funkciói a SharePoint portál legnagyobb „foglalási egységén”, egy site-on kapnak helyet. Ide helyezhetők el a dokumentumtárak, listák, feladatok 30 A SharePoint Server 2007 működésével kapcsolatos beállítások az adminisztrátorok számára készített portálon, a Central Administration-ön tehetők meg. A rendszer telepítése után az Administrative Tools / SharePoint 3.0 Central Administration menüpont alatt érhető el 67 és minden egyéb támogatott komponens. A kérvényezési feladatok elvégzéséhez a főoldalon található Site Actions menüpont Create Site opcióját választva lett létrehozva a Kervenyezes elnevezésű site a Blank Site template felhasználásával. Speciális esetben alkalmazható lett volna valamely specializált felületsablon

is, de teljesen egyéni megvalósítások esetében ez a megfelelő eljárás. A felület elkészültével meg kell határozni, hogy melyek azok a csoportok, akik hozzáférnek szolgáltatásaihoz. A műveletek a Site Actions/Site Settings opció People and Groups szekciójában lettek elvégezve, különböző jogokkal felruházva három szerepkört: Feldolgozok, Elbiralok és Menedzsment. 21. ábra A szerepkörök jogosultságai Az Active Directory-ban tárolt felhasználói fiókokat ezek után már hozzá lehetett adni a megfelelő csoportokhoz, szám szerint három feldolgozót, egy elbírálót és egy menedzsert. Az ábrán látható, hogy utóbbinak Contribute, azaz tartalomszerkesztési joga van, mely azt jelenti, hogy létrehozhat, törölhet és módosíthat felületi elemeket. A másik két szerepkör tagjai az ennél jóval korlátozottabb olvasási hozzáféréssel rendelkeznek. Internet Explorer böngésző használata esetén a tartomány számítógépe automatikusan

elküldi az authentikációs információkat a szervernek, így a SharePoint portálra való belépéskor nincs szükség további azonosításra. 5.32 Kérvény – és feladattárak létrehozása  A kérvénytár létrehozása A rendszerbe érkező kérvényeket tartalmazó dokumentumtár a View All Site Content opció Create funkcióján keresztül lett létrehozva. A támogatott fájltípusok közül a Microsoft Office Word Document – re esett a választás, megtörtént a verziókezelés alkalmazása és a site főoldalán való megjelenés érdekében engedélyezve lett a navigációs menübe való elhelyezés. A beállításokat a 22. ábra bekeretezett részei szemléltetik 68 22. ábra Kérvényeket tartalmazó dokumentumtár létrehozása A dokumentumtárban a fájlokhoz paraméterek egész sora tartozik, melyek tájékoztatnak a létrehozás és az utolsó módosítás dátumáról, a címről, a verziószámról, de ezek köre bővíthető. A kérvényeket

reprezentáló dokumentumok esetében tárolni kell a folyamat szerinti státuszt, az irat típusát és az elbíráló felhasználó azonosítóját. Mindhárom a tár tulajdonságait leíró lap Create Columns menüpontjában lett felvéve, szöveg típusú mezőként definiálva őket. A dokumentumtár alapértelmezett nézetének oszlopainak megváltoztatása a Modify this View opcióval történt. A minél jobb követhetőség és átláthatóság kedvéért az alábbi sorrend alakult ki:  Name – kérvény neve, rákattintva megnyílik a dokumentum  Version - verzió  Created – létrehozás időpontja  Modified – módosítás időpontja  KervenyStatusz – kérvény állapota, mely a specifikációban felsorolt értékeket veheti fel  Elbiralta – a jóváhagyási folyamatot végző felhasználó azonosítója  KervenyTipus – a rendszerleírásban ismertetett típusértékeket veheti fel  Jovahagyas – a jóváhagyási folyamat

állapota 69 23. ábra A kérvények dokumentumtára A dokumentumtár elemei a módosítás időtartama szerinti csökkenő sorrendben jelennek meg. A rendezési és szűrési értékek megváltoztatásához természetesen nem szükséges minden alkalommal a nézet beállításait konfigurálni, időszakosan a fejlécre kattintva is megtehető.  A kérvénytár jogosultsági beállításai A kérvények tárolására létrehozott dokumentumtár örökölt jogosultsági beállításai a rendszer működése szempontjából nem megfelelők. A Feldolgozo felhasználói csoport tagjai számára biztosítani kell, hogy az iratokhoz munkafolyamatokat rendelhessenek, ehhez viszont Contribute, azaz tartalompublikálási engedélyre van szükség. A menedzsment tagjainak hozzáférési körét ezzel ellentétben csökkenteni kell, mivel automatikusan megkapták a létrehozási, törlési és módosítási jogosultságokat. Mivel az ő szerepük kimerül abban, hogy elolvassák és

intézkednek a jóváhagyott kérvények ügyében, elegendő csupán a dokumentumok megtekintését engedélyezni számukra. A Document Library Settings/Permissions for this document library menüpontban kilistázott hozzáférési szintek szerkesztésével megszűnt az sitehoz való jogosultsági kötődés, egyedi szabályok léptek érvénybe. A kérvényeket tartalmazó dokumentumtár egészére kiadott csoportos engedélyek nem elegendőek az állományszintű láthatóság megvalósításához. Ezeket a beállításokat az iratokat rendszerbe érkeztető alkalmazásnak kell megtenni a következő oldalon található kódrészlet felhasználásával. A programrészletben az látható, hogy hasonlóan a dokumentumtár és a site esetéhez, itt is megszűnik a jogosultságok öröklése, méghozzá a BrakeRoleInharitance(true) hívás sorában. Fontos, hogy true értéket kapjon a függvény, mivel ekkor le is másolja a jogokat, így a többi, korábban megtett magasabb szintű

beállítás sem vész el. Ezt követően a kód törli a Feldolgozok csoport hozzáférését és csak az meghatározott személy számára teszi elérhetővé a kérvényt. A működésben mindez úgy jelentkezik, hogy hiába van valakinek olvasási engedélye a dokumentumtárhoz, az adott Jóváhagyásra vár állapotú kérvény csak a kijelölt személy számára lesz látható. 70 SPSite site = new SPSite("http://kervenyezes"); SPWeb web = site.OpenWeb("Kervenyezes"); SPFolder folder = web.GetFolder(http://kervenyezes/Kervenyezes/kervenyek); SPFile file = folder.FilesAdd(path, fileData); file.Properties["KervenyTipus"] = „LakasTamogatas”; file.Properties["KervenyStatusz"] = „JovahagyasraVar”; SPGroup gFeldolgozok = web.Groups["Feldolgozok"]; SPGroup gMenedzsment = web.Groups["Menedzsment"]; SPUser uFeldolgozo = gFeldolgozok.Users[username]; file.ItemBreakRoleInheritance(true);

file.ItemRoleAssignmentsRemove(gFelgolgozok); file.ItemRoleAssignmentsRemove(gMenedzsment); SPRoleAssignment raFeldolgozo = new SPRoleAssignment(uFeldolgozo); SPRoleDefinition rdContribute = web.RoleDefinitions["Contribute"]; raFeldolgozo.RoleDefinitionBindingsAdd(rdContribute); file.ItemRoleAssignmentsAdd(raFeldolgozo); file.ItemUpdate(); file.Update(); Az Elbiralo és Menedzsment csoportra vonatkozó jogok és mindennek a kérvényezési folyamattal való összefüggése a jóváhagyási workflow leírásánál kerül bemutatásra.  A kérvények rendszerezése A SharePoint-al kapcsolatos performancia okok és a rendszerezettség fenntartása érdekében a dokumentumtáron belül csoportokba kell rendezni a kérvényeket. Az utóbbi állítás magától értetődő, az első viszont magyarázatra szorul. A tapasztalat azt mutatja, hogy bizonyos adatmennyiség után egy SharePoint mappába ugyanarra a hierarchia-szintre nem ajánlott 3000nél több fájlt elhelyezni,

mert drasztikusan lecsökken a válaszidő. Természetesen nagy teljesítményű hardvereszközökkel ez a határ kitolható, de nem a végtelenségig, ezért mindenképpen érdemes struktúrába szervezni az állományokat. A megvalósítandó rendszerben kronológiai szempontok alapján történik a kérvények rendezése. A legfelső szintű mappa az évet határozza meg, az alatta lévők a hónapot, majd következnek a napok és végül az ugyanaznap érkezett dokumentumok egyenként azonosítva. Ezzel az eljárással napi 3000 fájl helyezhető el egy hierarchiaszinten, ami ha nem lenne elég, órák szerinti bontással lehet tovább finomítani a rendezést. A rendszer szempontjából ugyan megoldódott a teljesítmény-probléma, az emberi munkaerő hatékonyságára viszont könnyen negatív hatással lehet a módszer. A fejlett 71 keresőszolgáltatás ellenére előfordul, hogy a weboldalon történő navigálással hamarabb célt lehet érni, de ekkor a

könyvtárstruktúrában való bolyongás észrevehetően akadályozó tényezőként jelentkezik. Ezen a ponton jutnak szerephez a nézetek Lehetőség van választani, hogy eltárolásának megfelelően, hierarchiába rendezve jelenjen meg a tartalom, vagy a köztes szinteket átugorva közvetlenül a fájlok jelenjenek meg a listában a nézet szűrési és rendezési szabályainak megfelelően. A leírtakat figyelembe véve a rendszerben két View31 készült, melyek csupán az előzőekben tárgyalt aspektusban térnek el egymástól.  A feladattár létrehozása, konfigurációja Az elbírálók feladatait tároló lista létrehozása sok tekintetben azonos a dokumentumtár elkészítésének és konfigurálásának lépéseivel. Ebben az esetben Document Library helyett Tasks típusú SharePoint komponens lett létrehozva, mely Feladatok néven érhető el. A lista létezése egyedül az Elbiralok csoport tagjai számára bír jelentőséggel, ezért megbontva a

jogosultság-öröklési láncot, csakis számukra érhetőek el szolgáltatásai. Hatáskörük kiterjed törlésre, módosításra és létrehozásra (Contribute), ellentétben a Feldolgozok és Menedzsment tagjaival, akik még csak nem is láthatják azt. A feladattár elemei négy, a rendeltetésüket meghatározó dinamikus paraméterrel rendelkeznek:  Title – a feladat neve  Assigned To – a felhasználó, akire vonatkozik a bejegyzés  Link – a kapcsolódó dokumentumra (kérvényre) mutató URL  Created – a létrehozás időpontja 24. ábra A feladatok listája A megvalósított rendszerben ugyan csak egy elbíráló felhasználó tevékenykedik, de a kérvények számának növekedésével igény lehet további erőforrások bevonására. Annak érdekében, hogy mindenki csak a saját feladatait lássa a kijelzőn, létrehozhatóak személyes 31 View: Nézet 72 nézetek, amik az Assigned To oszlop szűrésével az aktuális felhasználó

számára fontos task-okat listázzák ki.  A Full-Text Search szolgáltatás beállítása A dokumentumok tartalmában való kereséshez aktivizálni kell a SharePoint Server 2007 által támogatott Full-Text Search szolgáltatást. A beállítás két lépésben zajlik, melyek a következők:  el kell indítani az SQL Server FullText Search Windows service-t  a SharePoint Central Administration weboldalon be kell állítani az indexelés periódusát 25. ábra A tartalomindexelés beállítása A megvalósított rendszer 20 perces időközönként végez inkrementális adatgyűjtést. Ez azt jelenti, hogy nem nulláról kezdi építeni a keresési struktúrát, hanem csak a módosításokat (fájl törölve, új létrehozva, stb.) veszi figyelembe 73 5.33 A kérvény-elbírálási folyamat megvalósítása A rendszerspecifikációban tárgyalt kérvény-elbírálási folyamat a Kervenyek elnevezésű dokumentumtár állományainak workflow-által vezérelt

életciklusát mutatja be. Az első szakaszt – az irat megérkezésének körülményeit, Jóváhagyásra vár állapotba kerülést – már az előző fejezet részletesen ismertette. A második, harmadik és negyedik pontban megfogalmazott funkcionalitás megvalósítása előtt a mindhárom lépésben fontos szerepet betöltő értesítési eljárásról lesz szó.  Értesítések beállítása A rendszerarchitektúrának megfelelően a kérvényeket tartalmazó dokumentumtár és a feladatlista változásairól a felhasználók RSS hírcsatornákon keresztül fogadják az értesítéseket. A szolgáltatás a SharePoint alapbeállításaival nem kifejezetten használható, mivel a 60 perces frissítési gyakoriság nincs a gyors munkavégzés javára. Az optimális működés elérésének érdekében négy lépés végrehajtása szükséges. Elsőként a legfelső szinten lévő site-on, a Home-on kell beállítani, hogy a portálrendszer engedélyezze az RSS szolgáltatást

(Allow RSS Feed in this site collection). A konfigurációs panel lényeges eleme a Time To Live paraméter, ami az aktuális állapot élettartamát határozza meg, egyszóval a frissítés gyakoriságát. A 60 perces érték 5-re való cseréje már kielégítő működést biztosít. Második lépésként egy ugyanolyan felületen kell megadni ezeket az értékeket a Kervenyezes site beállításainál. Ezt követően a dokumentumtár és a lista konfigurációs felületének RSS Settings menüpontjában nyílik lehetőség a szolgáltatás részletes testre szabására. Meghatározható a cím, a leírás, a csatolmányok engedélyezése, illetve az értesítés paraméterei is, melyekhez a Modified elnevezésű lett manuálisan hozzáadva. Erre azért van szükség, mert így az RSS olvasó alkalmazásban az elemek utolsó módosításuk szerint csökkenő sorrendbe rendezhetők. Utolsó lépésként újra kell indítani a gazda operációs rendszert. A fenti lépések a

megvalósított rendszeren alkalmazva lettek, a hírcsatornákra való feliratkozás az internetböngészőből tehető meg legkényelmesebben. A technológia nagy előnye, hogy figyelembe veszi a feliratkozó személy authentikációs beállításait, így valóban csak azokkal a kérvényekkel/feladatokkal kapcsolatban kap értesítést, amikhez kellő jogosultsággal rendelkezik. A gyakorlatban ez azt jelenti, hogy a feldolgozó a beérkezet Jóváhagyásra vár állapotú kérvényekről, az elbíráló a számára kiírt feladatokról, a menedzsment tagjai pedig a Jóváhagyva vagy Elutasítva állapotba lépett dokumentumról szerez tudomást. 74  A workflow kialakítása A Visual Studio 2008 workflow designer felhasználásával elkészített, a Függelék 1. pontban megtalálható munkafolyamat valósítja meg a kérvény-elbírálási eljárást. Az activity-k eltérő színezése típusaikat hivatott megkülönböztetni. Az zölddel jelöltek eseménykezelőket, a

kékek bizonyos műveleteket, a szürkék pedig a fejlesztő programkódján keresztül kiadott utasításokat tartalmaznak. Ahhoz, hogy a dokumentumokkal együttműködjön, hozzá kell rendelni a dokumentum – és feladattárhoz. A projekt SharePoint Settings elnevezésű paneljén tehető meg mindez: 26. ábra Workflow hozzárendelése dokumentum - és feladattárhoz A program felkínálja továbbá, hogy engedélyezve legyen-e a workflow automatikus elindítása új elem létrehozása esetén. Mivel a kérvény beérkezése után a feldolgozónak még meg kell vizsgálnia azt, a megvalósított rendszer ezt az opciót nem alkalmazza a gyakorlatban. A munkafolyamat belépési pontja az onWorkflowActivated activity. Itt inicializálódik a workflow lényeges elemeit tároló objektum, mely a megoldásban a workflowProperty elnevezést kapta. Tartalmazza az indítást végző felhasználó adatait, a lista információit és referenciát a hozzárendelt dokumentumra. A folyamat

következő, TaskLetrehozas elnevezésű lépésében létrejön az elbírálóhoz rendelt feladat. Az eseménnyel egy időben lefut a következő oldalon található kódrészlet is, mely további beállításokat eszközöl a listaelemen. A taskProps a feladat tulajdonságait tartalmazó objektum, mellyel elérhetőek a bejegyzés paraméterei. A program beállítja az elnevezést (Title) és a címzettet (AssignedTo) Mivel elkezdődött a jóváhagyási folyamat, a workflowProperty segítségével a hozzárendelt dokumentum állapotát Jóváhagyás folyamatban-ra változtatja. A TaskType változó határozza meg, hogy milyen felület jelenjen meg akkor, mikor az elbíráló rákattint a feladatot reprezentáló 75 linkre. Alapértelmezésben egy, a lista oszlopainak megfeleltethető webform32 rajzolódik ki, melynek értékeit a felhasználó tetszése szerint változtathatja, majd elmentheti. taskID = Guid.NewGuid(); taskProps.Title = „Kérvény jóváhagyás”;

taskProps.AssignedTo = „KERVENYEZESharagospal”; taskProps.TaskType = 0; workflowProperty.Item["KervenyStatusz"] = "JovahagyasFolyamatban"; workflowProperty.ItemUpdate(); Mivel egy elbírálási folyamatról van szó, szövegmezők kitöltése és legördülő menük alkalmazása helyett egy egyedi felület tervezése jelenti az elegáns megoldást. A Microsoft Office InfoPath 2007 űrlapkészítő alkalmazás képes web-technológiákkal együttműködő felületek létrehozására. Az szoftverrel készített sablon egy xsn kiterjesztésű állomány, mely leírja a rajta elhelyezett kontrolok megjelenését és viselkedését. A SharePoint portál webfelületén való megjelenést az InfoPath Forms Services szolgáltatás teszi lehetővé, ami egy böngésző számára is feldolgozható kimenetet állít elő. 27. ábra A kérvényt elbíráló felület A projekt tulajdonságait és telepítési információit tartalmazó workflow.xml és feature.xml

állományokban eszközölt módosítások végeredményeképpen a fenti képernyő jelenik meg az elbírálást végző felhasználó előtt. 32 Interneten használatos adatbeviteli felület, mely tartalmazhat szövegmezőket, legördülőmenüket és egyéb elemeket, majd az információkat gombnyomás hatására továbbítja a szervernek. 76 A munkafolyamat harmadik activity-je (TaskValtozott) a Jóváhagy vagy Elutasít gombok által generált onTaskChanged esemény hatására aktivizálódik. Az elbírálás kimenetelétől függően beállítja egy változó értékét, melynek hatására az elágazás jobb – vagy baloldalán folytatódik a vezérlés. A Jovahagyas és Elutasitas activity-k abban különböznek, hogy a munkafolyamathoz tartozó dokumentum KervenyStatusz paraméterét Jóváhagyva vagy Elutasítva állapotba billentik. Minden más, az alábbi felsorolásban szereplő műveleteket mindkettő elvégzi:  a feldolgozó felhasználót és az elbírálók

csoportját megfosztja a kérvényhez való hozzáféréstől és láthatóságtól  a menedzsment tagjainak, akiknek eddig nem volt jogosultsága a dokumentumhoz, most engedélyezi az olvasást, s mivel logikailag egy új elem jelent meg számukra, az RSS szolgáltatás értesítést küld a fejleményekről  véglegesíti a változásokat A munkafolyamat utolsó lépésként lezárja a task-ot (TaskBefejezes), majd törli azt a listából. A kérvény életciklusa ezzel véget ért, a menedzsment a végkimenetel alapján megkezdheti az ügyintézést. A workflow az exportálását követően Jovahagyas néven kerül be a dokumentumtár funkciói közé, ezzel a feldolgozó jogosultsági csoportba tartozó felhasználók rendelkezésére bocsájtja szolgáltatásait. 77 5.34 Az üzleti intelligencia megvalósítása A kérvény-elbírálási folyamat hatékonyságáról és az általa mozgatott dokumentumok paraméter-statisztikáiból kialakított belső

állapotról az üzleti intelligenciát megvalósító automatizált munkafolyamatok és SharePoint eszközök tájékoztatják a menedzsment tagjait. A fejezet bemutatja, hogy a négy alkotóelem (Windows Workflow Foundation, SQL Server2005, Excel Services, SharePoint Dashboard) milyen szoftvermegoldások felhasználásával valósít meg komplex működést az elkészült rendszerben.  A folyamatvezérlés kialakítása Az adatgyűjtést elvégző munkafolyamatok menedzselése SharePoint feladatelemek paraméterein keresztül történik. A task-okat egy feladatlista tárolja, melynek elnevezése: BI Tasks. A komponenshez egyedül az adminisztrátornak van hozzáférése, ezért hasonlóan az elbírálási eljárásban látottakhoz, a többi csoport meg van fosztva olvasási jogától. A következő felsorolás a szabad paramétereket ismerteti:  Title: a folyamat neve  Refresh: a frissítés gyakorisága másodperc alapon  Allapot: a workflow állapota 

MailToName: azok a személyek, akik nem a Menedzsment csoport tagjai, de szintén igényt tartanak e-mail értesítésre  MailToAddress: az előző paraméterhez tartozó e-mail címek A listaelemek létrehozása és menet közben történő módosítása egy webformon történik, mely az elbírálási folyamatban egy InfoPath komponenssel lett kiváltva, de itt a célnak tökéletesen megfelel: 28. ábra Automatizált folyamatokat vezérlő felület Kiemelendő az Allapot elnevezésű paraméter, amely egy véges halmazból veszi értékeit: Aktiv, NemAktiv, Torolve. Az első kettő magától értetődő (végez adatgyűjtést vagy sem), a harmadik pedig jelzi, hogy a következő frissítésnél záruljon le a folyamat és törlődjön a 78 feladatelem. A folyamatok indítása a kérvényekével analóg módon történik, azaz a weboldalon manuálisan kell hozzárendelni a bejegyzést a megfelelő workflow eljáráshoz.  Az aggregációs folyamat kialakítása,

riportfelület összeállítása A workflow létrehozása A BI Tasks lista elemeihez rendelhető adatgyűjtő workflow felépítése a Függelék 2. pontban látható. Az adatok folyamatos frissítését egy, a Workflow Foundation eszközkészletében megtalálható előltesztelő while-ciklus33 valósítja meg. A vizsgált feltétel a feladatelem Allapot paramétere, melynek Aktiv vagy NemAktiv értéke esetén lép be az aktuális periódusba. Ha ez nem teljesül (Torolve), akkor a SelfDelete activity-re kerül a vezérlés, ami lezárja és törli a bejegyzést a listából. A ciklus első lépéseként (CheckAllapot) „manuálisan” frissül a munkafolyamat állapotát tartalmazó változó. Erre azért van szükség, mert ha az adminisztrátor a vezérlő felületen futás közben változtatja meg az értéket, arról a workflow-példány nem szerez tudomást. Az adatgyűjtés előtt be van iktatva még egy teszt, mely csak Aktiv állapot esetén engedélyezi a

műveletek elvégzését. Azért lett egy külön vizsgálat létrehozva, mert ezzel átmenetileg megszüntethető az adatbázis-beli értékek frissítése, majd igény szerint újraindítható anélkül, hogy új task-ot kelljen létrehozni. Az összes feltétel teljesülése esetén aktivizálódik a párhuzamos adatfeldolgozást végző Aggregalas elenvezésű Parallel típusú activity. A három szál mindegyike a SharePoint API-ját felhasználva csatlakozik a dokumentumtárhoz, egy-egy riporthoz kiszámítja az értékeket, majd elmenti az adatbázisba. A frissítés tárolteljárás-hívásokon keresztül valósul meg, mely az információkat a 29. ábrán látható módon tárolja Az első két tábla napi, – illetve havi szintű kimutatásokat tárol a kérvények típusai és állapotai alapján. A Tipus, Allapot és Amount paraméterek jelentése egyértelmű, a Period pedig azt határozza meg, hogy az adott érték az aktuális napra (d) vagy hónapra (m) vonatkozik. A

harmadik tábla a SharePoint bemutatásánál tárgyalt KPI-k számára szolgáltat információkat a Jóváhagyásra vár állapotú iratok mennyiségéről és a kérvény-elbírálás százalékos teljesítéséről. Mivel utóbbi az esetek többségében nem egész szám, típusául a lebegőpontos float lett meghatározva. A műveletek elvégzése után várakozó állapotba kerül a folyamat, melynek időtartamát a feladatelem Refresh paramétere határozza meg. 33 A while-ciklus egy programozás-technológiai elem. Akkor használatos, mikor nem lehet pontosan megadni az ismétlődések számát, mert az egy bizonyos feltételtől függ. Előltesztelőnek nevezzük, ha a ciklus lefutása előtt, és hátultesztelőnek, ha utána vizsgálja annak teljesülését. 79 Tábla neve T AggregAllapot T AggregTipus T AggregKPI Paraméter neve Paraméter típusa Allapot nvarchar(50) Amount int Period nvarchar(1) Tipus nvarchar(50) Amount int Period nvarchar(1)

KPITypeName nvarchar(50) Value float 29. ábra Az aggregációs adatbázis A kimutatások kialakítása A SharePoint Server 2007 webfelületén megjelenő riportok elkészítése előtt létre kell hozni két könyvtárat, melyek a komponenseket tartalmazzák:  megbízható forrást az Excel állományoknak  megbízható forrást az adatkapcsolat-leíróknak Mindez azért kiemelkedően fontos, mert így biztosítható, hogy csakis az adminisztrátor által jóváhagyott, megbízható forrásokból érkeznek adatok a portálra. A beállításokat a SharePoint Central Administration 3.0 rendszergazdai felületen kell megtenni a ShareServices szekció Trusted file locations és Trusted data connection libraries menüpontjaiban. Az első esetben egy, a Kervenyezes site-on korábban létrehozott, ReportExcel elnevezésű, Excel állományokat tároló dokumentumtár lett megadva. A konfigurációs felületen számos beállításra nyílik lehetőség. A legfontosabb a

megvalósított rendszerben alkalmazott követelmény, miszerint a kimutatások csak megbízható adatkapcsolatokat használhatnak: 30. ábra Biztonságos adatkapcsolat megkövetelése 80 Az úgynevezett Data Connection Library típusú listák a dokumentumtárakkal analóg módon adhatók a portálhoz. A bejegyzések mindegyike egy-egy ODC (Office Data Connection) kiterjesztésű állomány. Az elkészült megoldásban a ReportDCL elnevezésű adatkapcsolattár került a Trusted data connection-ök közé. A riportok kialakítása a Microsoft Office Excel 2007 alkalmazás segítségével történt. A szoftver támogatja az SQL táblákhoz való kapcsolódást, ezért összesen öt (a napi és havi jelentések külön számítanak) leíró állomány lett létrehozva. A táblázatkezelő és az adatbázis közötti információáramlás biztosítása után az ODC fájlok elmentésre kerültek a számukra kijelölt SharePoint könyvtárba. Az adatok időszakos frissítése

alapértelmezésben nem támogatott, ezért engedélyezni kellett, minek következtében percenként érkeznek az új információk. A riport megjelenítő felületen összesen öt (kapcsolatonként egy) kimutatás szerepel, melyből négy diagram típusú, ezért az Excel alkalmazásban lett elkészítve: az állapotok és típusok összesítése az aktuális napra és hónapra vonatkozóan. Az ötödik, KPI listát kiszolgáló forrás egy egyszerű táblázat formájában került mentésre a megbízható fájlokat tartalmazó SharePoint dokumentumtárba, melynek grafikus megfelelője a felületen állítható össze. Beépítés a weboldalra Az elkészült összesítések a portálon létrehozott Dashboard felületen jelennek meg. A Kervenyezes site-hoz hozzáadott, Reports elnevezésű könyvtárban foglal helyet a Napi riportok és a Havi riportok címet viselő webes kijelző. Előbbi három (két napi plusz KPI) , utóbbi pedig kettő ( két havi ) komponensből épül fel. A

diagramokat tartalmazó Excel állományok egy-egy Excel Web Access WebPart segítségével jelennek meg, mely az adatokból a böngésző által is elfogadott kimenetet generál. Az ábrák színükben és méretükben teljesen azonosak a táblázatkezelőben tapasztalttal, egyedül az extraként alkalmazott háromdimenziós – és árnyékhatások tűnnek el. A komponens alapbeállításai lehetővé teszik a munkalap szerkesztését, adatok felvitelét és az elemek méretezését. A megvalósított rendszer szempontjából ezeknek a funkcióknak nincs jelentősége, sőt, illetéktelen személyek esetén biztonsági kockázatot is jelentenek, ezért a navigációs és editáló panelek ki lettek kapcsolva. A kijelzőhöz tartozó Excel állomány ugyan percenként frissíti magát az adatbázisból, de a felületen csak a Periodically Refresh if Enabled in Workbook jelölőnégyzet kiválasztása esetén látszódnak a változások. A leírt beállításokkal egy már-már

vastagklienseket megközelítő tudású, kényelmes megoldás lett kialakítva. A KPI lista elkészítése már egy több lépésből álló folyamat eredményeként zajlott. A site által támogatott könyvtártípusok között található a KPI List elnevezésű, melynek elemei egy-egy dinamikus adatkapcsolatból veszik értékeiket. A megvalósított rendszerben található KervenyKPI ennek egy példánya, mely az Excel 2007-ben összeállított munkalap adatait 81 dolgozza fel. A listához való hozzáadáskor ki lettek választva a monitorozott cellák, melyek a vizsgált értéket és a három minősítési szinthez tartozó (rossz, közepes, kiváló) két értékhatárt tartalmazzák. 31. ábra KPI lista beállítása A beállításokat követően a Dashboard-on elhelyezésre került egy Key Performance Indicators típusú WebPart, mely a KervenyKPI elnevezésű lista elemeit jeleníti meg a webfelületen. A havi és napi szintű riportok közötti kényelmes

navigálást egy sajátkészítésű WebPart segíti. A Visual Studio 2008 projektjei között található meg egy template, amivel SharePoint-ba exportálható komponensek hozhatók létre. A fejlesztést megnehezíti, hogy a megjelenítést ellentétben az ASPX oldalakkal nem lehet HTML nyelven kialakítani, hanem programozott felületi elemekből kell építkezni. A Dashboard tetején elhelyezett komponens egy legördülőmenüt tartalmaz, mely a Reportok könyvtárban található jelentések között vált, ha módosul a kiválasztás. A technológiával ennél jóval bonyolultabb, a SharePoint-ban is megfigyelhető építőelemek hozhatók létre, de a nehézkes design miatt jóval több időt vesz igénybe. A megvalósított, végleges Dashboard a 32. ábrán látható 82 32. ábra A kérvényezőrndszer riportfelülete  A jelentésküldő folyamat megvalósítása A riportkészítő workflow és a SharePoint webfelület együttesen egy online megoldást nyújt a

rendszer működésének nyomon követésére. Az üzleti intelligencia által nyújtott szolgáltatás azonban csak abban az esetben teljes értékű, ha akkor is támogatja az információszerzést, amikor kéznél modern internetböngésző. A specifikációban ismertetetett, nap – és hónapvégi e-mail üzenetek pontosan ezt a célt szolgálják. A workflow elkészítése A jelentést küldő munkafolyamat (Függelék 3.) felépítésében és működésében több ponton megegyezik adat-aggregációt készítő (Függelék 2.) társával Az ismétlések elkerülése végett csak a lényeges különbségek lesznek kiemelve. A ciklus és az állapotellenőrzések az adatgyűjtő munkafolyamatéival teljesen analóg módon működnek. A task esetén megadható MailToAddress és MailToName paraméterek ebben a workflow-ban, az értesítések kiküldésénél kapnak szerepet. Az Aktiv státusz ellenőrzése után a SetNotificationType activity-re kerül a vezérlés, mely az

értesítés típusát hivatott beállítani. Abban az esetben, ha az óra este 23-at mutat, megvizsgálja, hogy az adott hónap utolsó napja van-e. Ha igen, havi jelentést küld, ha nem, akkor napit. Minden egyéb esetben a Delay activity-re ugorva a Refresh változóban meghatározott számú másodpercig felfüggeszti működését. A CollectDailyData és CollectMonthlyData szakaszokban hasonlóan az előző munkafolyamathoz, a SharePoint API-ján keresztüli adatgyűjtés történik. Az adott időszakra 83 vonatkozóan lekérdezik a jóváhagyott, elutasított és az összes kérvény számát, ami kellően pontos statisztikát szolgáltat az eredményességgel kapcsolatban. Az információk megszerzését követően kerül sor az e-mail értesítések kiküldésére. A SharePoint által szállított SendEmail activity is alkalmas lett volna a feladatra, ehelyett inkább egy saját készítésű webservice34 meghívásával lett megoldva. Mindez azt szimulálja, hogy ha az

SMTP szerver nem tartózkodik a portálrendszerrel egy tartományban vagy zónában, köztes szolgáltatáson keresztül készíthető működő megoldás. Az InvokeWorkflow activity tulajdonságainál ki lett választva a webszolgáltatás megfelelő függvénye, s a szükséges paraméterek is átadásra kerültek. Szerepel köztük többek között a jelentéssel kapcsolatos számértékek sorozata, a címzett neve (MailToName) és e-mail címe (MailToAddress). Az üzenet elküldését követően a korábban már említett Delay activity-re kerül a vezérlés, ami az adminisztrátor által beállított időtartamig várakozik a következő periódus futtatására. Az e-mail szolgáltatás megvalósítása A rendszer e-mail értesítéseit az IIS35-ben futtatott webszolgáltatás küldi el a címzetteknek. A paraméterként kapott adatok alapján címenként összeállít egy XML fájlt, mely az alábbi módon épül fel: <?xml version="1.0"

encoding="utf-8"?> <?xml-stylesheet type=text/xsl href=C:DiplomaXSLTmonthly.xslt?> <root> <ToName>Kovács János</ToName> <Year>2009</Year> <Month>április</Month> <Osszes>413</Osszes> <Elbiralatlan>189</Elbiralatlan> <Jovahagyva>125</Jovahagyva> <Elutasitva>99</Elutasitva> </root> 34 A webservice – magyarul webszolgáltatás – programok közötti adatcserére szolgáló protokollok és szabványok gyűjteménye. Többnyire különböző programnyelveken írt és különböző platformokon futó szoftverek együttműködésének biztosítása értekében alkalmazzák. 35 Az IIS (Internet Information Services) a Microsoft szerver rendszereinek meghatározó komponense. Feladata hálózati szolgáltatások megvalósítása, melyek között megtalálható az FTP, a HTTP és a levelezés támogatása. 84 A webservice a második sorban hivatkozott XSLT36 állomány

felhasználásával állítja elő a formázott HTML kimenetet, ami a kiküldött e-mail megjelenését véglegesíti. A megvalósított rendszer a Google Inc.37 által üzemeltetett G-mail levelezőszolgáltatás regisztrált fiókján keresztül küldi el a leveleket. A webszolgáltatással kapcsolatban lényeges kiemelni, hogy egyirányú, tehát a hívó félnek (jelen esetben a munkafolyamatnak) nem kell megvárnia a függvény visszatérését, hanem egyből folytathatja a végrehajtást. 33. ábra A jelentést tartalmazó e-mail üzenet 36 Az XSLT (Extensible Stylesheet Language Transformations) egy XML-alapú nyelv, melyet XML dokumentumok más formátumra alakításához használnak. Az esetek többségében a kimeneten a kapott adatokat tartalmazó, jól formázott HTML, XHTML vagy PDF kiterjesztésű dokumentumok jelennek meg. 37 A Google, Inc. egy amerikai, tőzsdén bejegyzett részvénytársaság, amit eredetileg magánvállalatként alapítottak 1998-ban. Nevéhez

fűződik a legnépszerűbb keresőmotor, a Google kifejlesztése és üzemeltetése. 85 5.35 A rendszer értékelése A nagyszámú, önmagában is kellően komplex komponensből építkező megoldás hibamentes működésének garantálása izgalmas feladat elé állítja a fejlesztőket. Az alkotóelemek kommunikációját biztosító interfészek gyakran a cél elérése előtt bizonyulnak elégtelennek, ami a rendszerterv alapos újragondolását teszi szükségessé. Az alkalmazások elfogulatlan, minden részletre kiterjedő szisztematikus vizsgálatát a tesztelők végzik. Munkájuk során projekttől függően felállítanak egy vagy több tesztrendszert, melyet a fejlesztőkkel együttműködve folyamatosan frissítenek. Együttműködésüket a negyedik fejezetben ismertetett Team Foundation Server eszközkészletével tehetik hatékonnyá, ahol a hibák, és azok megoldásának dokumentálása a nap minden órájában rendelkezésre áll. E két munkacsoport

kooperációja az egyik legjobb példa arra, hogy az általános célú csoportmunka alkalmazásokat készítő informatikai szervezetek nem csak szoftverekbe implementálják, de alkalmazzák is a groupware diszciplínáit.  A tesztrendszer kialakítása A nagy és komplex rendszerek esetében nem várható el, hogy minden tesztelő saját számítógépén alakítson ki tesztkörnyezetet. Sokkal kézenfekvőbb egy komoly hardverelemekkel felszerelt szerverre natívan vagy virtuális gépként telepíteni a végleges megoldás pontos másolatát, és távoli asztali kapcsolattal menedzselni azt. A kérvényezési rendszer esetén egy VMware képfájl lett létrehozva, mely 1500 MB RAM-ot és egy kétmagos Intel Core2Duo processzort kapott erőforrásul. Mivel a gazdaoperációs rendszer számára hálózatba kapcsolt számítógépként látható a virtuális kliens, a natívan futó böngészőből is elérhető a portálrendszer. Tekintve, hogy nem ipari teljesítményű

szerverről van szó, az adatok csupán tájékoztató jellegűek. A teszteléshez egy konzolalkalmazás segítségével félévnyi tesztadat került be a Kervenyek elnevezésű dokumentumtár kronologikus hierarchiájába, hozzávetőlegesen 7000 elem.  A tesztek eredménye A kérvényeket tartalmazó dokumentumtárban való navigálás sebessége kiemelkedően fontos a feldolgozók hatékonyságának szempontjából. A nézetek közötti váltás, a szűrések, rendezések maximum 1,5 – 2 másodpercet vettek igénybe, ami webalkalmazás esetén elfogadhatónak számít. A munkafolyamatok indítása becslések szerint nem történik fél óránál gyakrabban, ezért sebességével kapcsolatban nem kell a webes interfész használatához hasonló követelményeket támasztani. A rendszer által igénybe vett 3 másodperc az elfogadható kategóriába esik A 86 követelményeknek megfelelően azonnal elkezdődött az adatok aggregálása, illetve megtörtént a feladatok

kiírása, tehát a rendszer megfelelő működést produkált. Az elbírálási workflow-k végén az állományok verziója a kívánt értékkel, tehát kettővel nőtt, így a Version History segítségével nyomon követhetők voltak a változások. A harmadik teszt a Dashboard felületet érintette. A SharePoint Server 2007 első indulásakor az oldalak lassan töltődnek be, ez különösen igaz a riportokra. Mivel itt nem csak magát a felületet kell beölteni, hanem a különböző Excel és KPI kijelzők adatait is, kezdetben 20-25 másodpercig kellett várakozni. Az ezt követő oldallehívás már az elfogadható 3 másodperc alatt történt meg, majd percenként frissült a tartalom. A megjelenítés helyessége elbírálási folyamatok szimulálásával történt. Amikor a frissítésért felelős workflow NemAktiv állapotban volt, az adatok változatlanok maradtak, majd az Aktiv-ba állítás hatására megjelentek a helyes információk. A negyedik, s egyben végső

teszt a jelentések küldését vizsgálta. Az állapot beállításokra ebben az esetben is pozitívan reagált a rendszer, csak akkor küldte el az emaileket, amikor aktivizálva volt a feladatelem. A funkció kritikus pontja az időzítés, melynek tesztelése az aktuális dátum külső erőforrásból – szöveges állományból – való betöltésével történt. A vizsgálat verifikálta a workflow működését, mivel csak a hónap utolsó napján 23 órakor küldött havi, s mindegy egyéb nap 23:00-kor aznapi jelentést.  A tesztek konklúziója Az eredményekből kiderül, hogy a megvalósítás funkcionálisan kielégíti a specifikáció követelményeit. A rendszer teljesítményének hiteles tesztelése csak ipari környezetben oldható meg, mivel a SharePoint Server 2007 nagy terhelés esetén már komoly hardvererőforrásokat igényel. A tesztgépen való működés közben, egy felhasználó kiszolgálásával közelítőleg 900 MB RAM-ra volt szüksége, ami

20-30 fő és nagyobb adatmennyiség esetén többszörösére nőhet. A Microsoft 4 GB installálását javasolja, ami alátámasztja a tényt, hogy nagy és komplex szoftverrendszerek megvásárlása és alkalmazása esetén megfelelő hardveres háttér nélkül nem fog megtérülni a befektetés.  Értékelés további szempontok alapján Kódminőség A .NET platform által nyújtott kényelmi szolgáltatások felhasználásával könnyedén készíthető jól olvasható, átlátható programkód. A rendelkezésre álló, előre elkészített osztálykönyvtáraknak köszönhetően bármely, C# fejlesztésben jártas szakember értelmezni tudja a működését, s kis időbefektetéssel módosíthatja is azt. 87 A rendszer forrása egy tesztadatokat feltöltő konzolalkalmazásból, a három munkafolyamatból, a dashboard-ok közötti váltást lehetővé tévő WebPart-ból és az e-mail küldést megvalósító webszolgáltatásból áll. Közös jellemzőjük a

kommentezés kellő részletessége, segítve az eligazodást a függvények és változók sokaságában. A workflow projektek grafikus nézete nagyban megkönnyíti a működés megértését, s az activity-ket kiválasztva azonnal megtekinthető a hozzájuk rendelt mögöttes logika. A hibakezelés mindenhol nagy hangsúlyt kapott, hibásan átadott paraméterek esetén sem omlik össze az alkalmazás (pl. rossz e-mail cím) A változók futásidőben történő javítását követően garantált azok érvényre jutása, s a folyamat helyes lefutása. Újrafelhasználhatóság A Visual Studio 2008-ban elkészült WebPart és munkafolyamatok előnye, hogy önálló komponensek, melyek tetszőlegesen telepíthetők bármely SharePoint Server 2007 kiszolgálóra. Erre lehetőség nyílik akár a fejlesztőeszköz Deploy parancsának kiadásával, vagy a melléklet BINARY könyvtárában található WSP kiterjesztésű állományok parancssoros installálásával. A nehézséget az

jelenti, hogy eltérő rendszerek más-más elnevezésű szerveren futnak. Mivel a workflow-k az aktuális számítógépen található SharePoint mappákon végeznek műveleteket, a címzéshez elengedhetetlen a megfelelő URL rendelkezésre állása. Az újrafelhasználhatóság támogatása végett a kódban dinamikusan, az aktuális környezet tulajdonságai alapján kerülnek összeállításra az elérési útvonalak. Az e-mailt küldő webszolgáltatás a már implementált webes metódusok alapján tovább bővíthető, s a konfigurációs állományban megadott authentikációs információk megváltoztatásával tetszőleges SMTP szerverrel működtethető. Architektúra A rendszer architektúrájával kapcsolatos megállapítások az 5.23-as pontban részletesen kifejtésre kerültek, ezért a szakasz csak kiegészítő állításokat tartalmaz. A megoldás heterogenitásának köszönhetően a komponensek nagy szabadsággal testre szabhatóak és a működés

optimalizálható. Az SQL Server 2005-ben tárolt komplex, a SharePoint tartalmát leíró adathalmazból az indexelési szolgáltatás segítségével milliszekundumok alatt kinyerhető a szükséges információ. Természetesen minél nagyobb adattömeget kell átvizsgálni, annál hosszabb a válaszidő, ezért lehetőség van több kiszolgálót összekötni és klaszterben38 működtetni, tehát a rendszer jól skálázható. 38 Különálló, általában homogén számítógépekből létrehozott, egységes rendszerképet biztosító virtuális gép. A teljesítmény növelésének érdekében párhuzamosan több, lazán csatolt gépen történik a feldolgozás, melyek kifelé egy csomópontnak látszódnak. 88 A SharePoint Server 2007 egyszerre valósítja meg az üzleti logikai és megjelenítési réteget. A szerveroldali komponensek bővíthetőségének köszönhetően tetszőleges funkcionalitás implementálható, ami nem lépi túl a WebPart

technológia korlátait. Akár saját listák, dokumentumtárak és egyéb, már létező szoftverkomponensek is hozzáadhatóak a rendszerhez, kiszolgálva az egyéni igényeket. A webszerverek is könnyen túlterhelődhetnek bizonyos látogatószám elérése után, ezért a SharePoint Server úgynevezett farmokba szervezhető, ahol több kiszolgáló fogadja a kéréseket. A leírtakból látszik, hogy az architektúra, kihasználva a portálrendszer rugalmasságát, hardveresen és szoftveresen egyaránt kiterjeszthető, ami hosszú időre biztosítja a szervezet informatikai támogatását a választott platformon. 89 6. Összefoglalás A szoftveripar által termelt, önmagukban is sokoldalú alkalmazások összekapcsolása jól definiált interfészek rendelkezésre állása esetén is izgalmas mérnöki feladat, hiszen számtalan lehetőség kínálkozik, melyek között ugyanúgy akadnak sikeres, mint kudarcra ítélt megoldások. Az informatikai fejlesztésekkel

foglalkozó szervezetek többsége mindent megtesz annak érdekében, hogy az ügyfél számára értékes, minden szempontból optimális konfigurációt állítson elő, de a hiányos specifikáció és az egymásnak ellentmondó követelmények akadályok egész sorát gördíthetik a sikeres projektzárás útjába. A szoftverfejlesztési metodológiák iránymutatásainak követésével minimalizálhatók az említett kellemetlenségek, s a cég profiljának megfelelő, stabil munkamenet alakítható ki. Az informatikai cégeknél alkalmazott csoportmunka módszereket általánosítják a kereskedelmi forgalomban kapható, vagy egyéni igények szerint összeállított groupware rendszerek. A szigetmegoldások rugalmatlansága következtében megjelenő hiányosságokat és konfliktusokat sikeresen szüntetik meg a szoftveresen támogatott munkafolyamatok, s biztosítják a tevékenységek összehangolását illetve nyomon követhetőségét a projekt egész életciklusára

vonatkozóan. A megfigyelésük alapján, a rendszer belső működésére és a piaci igényekre való gyors reagálás lehetősége sokáig csak a jelentős anyagi tőkével rendelkező szervezetek kiváltsága volt, de a hardverek fejlődésének és a készen vásárolható BI megoldásoknak köszönhetően mára a kis – és középvállalkozások számára is elérhető. A dolgozatban megtervezett architektúra a komponensek együttműködését felhasználva valósít meg egy olyan minta-üzleti intelligenciát támogató rendszert, mely az említett hiányosságokat kiküszöböli, s a szolgáltatásokat magában foglalja. A kialakítás során előfordult, hogy választani kellett konkurens technológiák között, de a követelményekben leírtak többnyire egyértelművé tették a Microsoft eszközeinek alkalmazását. A Microsoft SQL Server 2005 és a Workflow Foundation helye a kezdetektől megvolt a projektben, de a SharePoint Server 2007 esetében ellentmondás alakult

ki a ráfordított idő és az ár tekintetében. Magától értetődő, hogy az elvárás, mi szerint egy jól működő megoldást kell olcsón és gyorsan elkészíteni, mind a fejlesztést végző cégnek, mind a megrendelőnek érdeke, hiszen előbbi hamarabb kapja meg a termék ellenértékét, utóbbi pedig elkezdheti használni azt. Mindhárom feltétel teljesítése nem realizálható, ezért alapos vizsgálódás után az első és harmadik (minőségi termék, gyorsan) mellett történt állásfoglalás, mivel a másik alternatíva (fejlesztés a kezdetektől, olcsóbban) nem garantálja sem a hibamentességet, sem a határidőre való elkészülést. A SharePoint Server 2007, mint központi technológia a többi említett szoftvereszközzel együttműködve garantálja a megbízható, folyamat orientált működést, ami által a megvalósított rendszer valódi üzleti értéket képvisel. 90 A fejlesztés lehetőségekkel kapcsolatban mindenképpen ki kell emelni a

mobil eszközökkel való integrációt. A SharePoint beépítetten támogatja a listák és egyéb objektumok miniatűr kijelzőn való megjelenítését, de a riportok esetén optimalizációra van szükség. Az email és RSS üzenetek mellett hasznos újítás lehet az SMS szolgáltatás kihasználása jelentések küldésére vagy váratlan eseményekről való gyors tájékoztatás céljából. Az új technológiák bevonása mellett egyéb folyamatok és dashboard-elemek létrehozása tovább színesítheti a rendszer által hordozott funkcionalitást. A csoportmunkát, munkafolyamatokat és üzleti intelligenciát támogató eszközök a civil – és közszférában számtalan esetben bizonyították, hogy alkalmazásukkal hatékonyság növekedés és szervezeti stabilitás érhető el bármely szakterületen. A jövőben tehát azok a megoldások tudnak széles körben érvényesülni, melyek kihasználva az interoperabilitásban rejlő lehetőségeket, támogatják a

kooperációt, koordinációt és kollaborációt az informatikát tudatosan alkalmazó professzionális ipari szereplők körében. 91 Köszönetnyilvánítás Szeretnék köszönetet mondani egyetemi konzulensemnek, Oláh Istvánnak a diplomamunka megírásához, a hibák felderítéséhez és a szakmai színvonal növeléséhez nyújtott támogatásáért. Továbbá köszönöm külső konzulensemnek, Garami Gábornak, hogy felkeltette érdeklődésemet a téma iránt, bepillantást nyújtott az ipari szintű szoftverfejlesztés kulisszáiba és jó tanácsaival, ötleteivel segítette munkámat. 92 Melléklet tartalma DB SPBACKUP Az aggregációt eltároló adatbázis mentése A SharePoint portál biztonsági mentése, melyből visszaállítható a teljes tartalom BINARY WSP telepitesi leiras.pdf A munkafolyamatok bináris telepítői Az adatbázis, az e-mail szolgáltatás és a workflow-k telepítésének módját leíró segédlet diplomaterv.pdf A diplomaterv

PDF formátumban bemutato.wmv A rendszer fő funkcióit bemutató videó DIPLOMA eDOCUMENT Az elektronikus forrásanyagok HTML és PDF formátumban DiplomaSolution EXCEL SOURCE INFOPATH ODC XSLT A megvalósított rendszer Visual Studio 2008 projektjei Az Excel Services által feldolgozott Excel állományok Az InfoPath Forms Services által megjelenített kérvény jóváhagyási form A megbízható adatkapcsolatokat leíró állományok Az e-mail üzenetek HTML formátumát előállító XSLT állományok 93 Irodalomjegyzék [1] J.H Erik Andriessen: Working with Groupware Springer, 2003 [2] Gábor András: Intelligens Iroda Aula, 1997 [3] Dr. Horváth Zsolt: Áttekintés a CMMI alapjairól http://www.infobizhu/cmmi12html [4] Szűcs Géza: Szoftverfejlesztési módszertanok http://www.freewebhu/flextor/devmethodhtml [5] Mező Attila: Webes alkalmazásfejlesztés, Report Request Form Debrecen, 2008 [6] Richard Hundhausen: Fejlesztői csoportmunka – Visual

Studio 2005 Team System SZAK Kiadó, 2003 [7] Molnár Ágnes: Testreszabott szoftverfejlesztési módszertanok http://aghy.uwhu/mq/mqhtml [8] Bill English, The Microsoft SharePoint Community Experts: Microsoft Office SharePoint Server 2007 Administrator’s Companion Microsoft Press, 2007 [9] Molnár Ágnes: SharePoint 2007 Funkcionális áttekintés http://devportal.hu/groups/office/pages/sharepoint-2007-funkcion-225-lis-225-ttekint233-saspx [10] Frank Péter, Tordai László: Üzleti intelligencia eszközök megismerése Önálló labor, 2009 [11] Microsoft Corporation: Excel Services Technical Overview http://msdn.microsoftcom/en-us/library/aa972194aspx [12] Microsoft Corporation: Deliver Business Intelligence through Microsoft Office SharePoint Server 2007 http://office.microsoftcom/en-us/sharepointserver/HA101747701033aspx [13] Microsoft Corporation: Introduction to Business Intelligence features http://office.microsoftcom/en-us/sharepointserver/HA100872181033aspx [14]

Microsoft Corporation: Introduction to the Report Center http://office.microsoftcom/en-us/sharepointserver/HA101741991033aspx [15] Kenn Scribner: Microsoft Windows Workflow Foundation Step by Step Microsoft Press, 2007 94 Függelék 1. A kérvény-elbírálási munkafolyamat 95 2. Az aggregációt végző munkafolyamat 96 3. A jelentésküldő munkafolyamat 97