IT Controlling tanfolyam. Az informatikai fejlesztés controllingja

Véry Zoltán

IT Controlling tanfolyam Az informatikai fejlesztés controllingja

Budapest, 2007.

Az informatikai fejlesztés controllingja

TARTALOMJEGYZÉK

1.

AZ INFORMATIKAI FEJLESZTÉS ÉS AZ ÜZLET KAPCSOLATA............... 3

2.

AZ INFORMATIKAI FEJLESZTÉS TARTALMA ÉS ÖSSZETEVİI ............. 4

3.

A SZOFTVERFEJLESZTÉS RENDSZERE.......................................................... 5

3.1

Tervezési alrendszer..............................................................................................................................................5

3.2

Fejlesztési alrendszer ............................................................................................................................................5

3.3

Ellenırzési alrendszer ...........................................................................................................................................5

3.4

Irányítási alrendszer .............................................................................................................................................7

3.5

Implementációs alrendszer...................................................................................................................................7

3.6

Információs- és dokumentációs alrendszer .........................................................................................................8

4.

ALKALMAZOTT SZOFTVERFEJLESZTÉSI MÓDSZEREK ÉS ESZKÖZÖK8

4.1

Teljes életciklus szemlélet: Vízesés Modell .........................................................................................................9

4.2

Teljes életciklus szemlélet: V-MODELL .............................................................................................................9

4.3

Célvezérelt projektmenedzsment (GDPM) .......................................................................................................11

4.4 AGILIS fejlesztési módszerek ............................................................................................................................12 4.4.1 Dinamikus Rendszerfejlesztési Modell (DSDM) ..........................................................................................12 4.4.2 SCRUM Modell ............................................................................................................................................17

5.

A SZOFTVERFEJLESZTÉS MINİSÉGBIZTOSÍTÁSA................................. 20

5.1

CMMI – minıségvezérelt projektmenedzsment...............................................................................................20

5.2

Six Sigma (6б .......................................................................................................................................................21

6.

RENDSZER- ÉS SZOFTVERFEJLESZTÉSI CONTROLLING...................... 22

Szerzı: Véry Zoltán

Kiadó: BMS Informatikai Kft., 2007.

Minden jog fenntartva, beleértve a másolás, a sokszorosítás, a bıvített és rövidített kiadás,illetve az elektronikus adathordozón megjelentetés jogát.

2./24



A fejezetben tárgyalt témák: • • • • • •

Az informatikai fejlesztés és az üzlet kapcsolata Az informatikai fejlesztés tartalma, összetevıi Az üzlet és az informatika összehangolása Az informatikai fejlesztés rendszere és funkciói Rendszer- és szoftverfejlesztési módszerek A szoftverfejlesztés felügyelete és szabályozása

1. Az informatikai fejlesztés és az üzlet kapcsolata Globalizált, hálózatos világunkban a vállalkozások üzleti modelljében az információs rendszer egyre inkább stratégiai elemmé válik. Az informatika szerepe átértékelıdik, a vezetık sokkal nagyobb hangsúlyt fektetnek az informatikai fejlesztések irányának meghatározására. A fejlesztéseknél mindig a stratégiai célokból kell kiindulni. Az alkalmazásoknak illeszkedniük kell az üzleti folyamatokhoz. Az üzleti folyamatokra azonban a gyors és gyakori változások jellemzıek, melyek követése a szoftverekben nem könnyő feladat. A fejlesztések egyik generálója az üzleti folyamatokban bekövetkezett változások leképezése az információs rendszerben. A változások sokféle okból következhetnek be, például: • Változnak a jogszabályok, szabványok, amelyeknek meg kell felelni; • Új termékeket, szolgáltatásokat vezetünk be a piacon; • Új vevıkört akarunk meghódítani; • Változik a szervezeti struktúra; • Változnak a mőködési folyamatok; • A felhasználók új információs igényekkel lépnek fel; • Online folyamatokat alakítunk ki; • Új felhasználói csoportok lépnek be a rendszerbe. További fejlesztést generáló tényezık például: • A meglévı erıforrások már nem elegendıek az üzemszerő mőködéshez; • Az alkalmazott információtechnológia elavult, a gyártók által nem támogatott; • A rendszer nem elég biztonságos; • Az adatbázis mérete és növekedési üteme meghaladja a tervezett szintet.




3./24


2. Az informatikai fejlesztés tartalma és összetevıi Az információtechnológia progresszív ágazat. Az ágazati innovációs hullámok folyamatos hatást gyakorolnak az üzlet és Innovációs hajtóerık ill. Üzleti igények, követelmények társadalom összes szereplıjére. Az IT képessé tesz. Képessé Üzletfejlesztés Rendszerfejlesztés Eszközfejlesztés Képességfejlesztés tesz arra, amit nélküle képtelenek lennénk megtenni. Képessé tesz a magas szintő szellemi munkára és együttmőködésre, kommunikációra. Fontos azonban, hogy állandó összhangot teremtsünk és tartsunk fenn, üzlet és technológia között. A technológiai hardver és szoftver BIZ IT IT / BUSINESS ÖSSZEHANGOLÁS eszközök illetve módszerek fejlesztése mellett, fejlesztenünk kell az orgver (szervezeti) eszközöket, illetve módszereket egyaránt. Azaz a folyamatokat, az üzleti funkciókat, az üzleti modellt, az integritást, az alkalmazásokat, az információkezelési szabályokat, a projektvezetési módszereket és a felhasználók képességeit egyaránt. A rendszerszerő gondolkodás, illetve a rendszerelvő fejlesztés ezt kívánja. A minıségirányítás (minıségbiztosítás, minıségellenırzés) is ezt várja el tılünk. Az informatikai fejlesztések, ma már, üzletfejlesztéssel is együtt jár(hat)nak. Az információtechnológia és üzleti stratégia, hatással vannak egymásra. Szinergiahatással. Képzés, továbbképzés

Módszer-fejlesztés

Software-fejlesztés

Alkalmazás-fejlesztés

Architektúra-fejlesztés

Rendszerintegráció

Funkció fejlesztés

Folyamatfejlesztés

Informatikai fejlesztések aspektusai

Az információtechnológia üzleti folyamatokat is megvalósít, illetve támogat. A folyamatok definiálása nélkülözhetetlen az IT-rendszer helyes kialakításához. Ezért gyakori, hogy egy új alkalmazás bevezetése együtt jár a mőködés folyamatrendszer átgondolásával, esetleges átszervezésével (BPR – Business Process Reengineering). Az üzletmenetre egyre inkább jellemzı a változékonyság. A növekvı vevıi igények kielégítése, a termékfejlesztés, a szolgáltatások bıvítése, ill. átalakítása, a szervezeti-mőködési rendszer változtatása, a jogszabályok változása – mind olyan tényezı, amely szükségessé teszi az informatikai rendszer folyamatos változtatását is, hogy megfeleljen az új követelményeknek. Ennek megvalósításához az informatikai csapatnak szorosan együtt kell mőködnie a szervezettel, idıben értesülnie kell a tervezett változásokról, hogy felkészíthessék ezekre az ICT rendszert. Az informatika a fentiek alapján nemcsak egy szakterületi funkció, amely speciális tudást igényel, hanem része a stratégiai tervezésnek és irányításnak is. Ezt ábrázolja az alábbi ábra:




4./24


3. A szoftverfejlesztés rendszere A szoftverfejlesztés széleskörő, összetett szakterület, többféle szakemberrel, számtalan fejlesztési céllal, eszközzel és módszerrel. Szoftvereket készítünk a társadalom szinte összes területére. A kutatás, a mőszaki fejlesztés, az üzleti verseny, a kommunikáció, az automatizálás, a személyes eszközhasználat, az egészségügy, a szolgáltatások, a kormányzás, a védelem, stb. mind használnak szoftvert. A szoftver egy eszköz, mely beépült az életünkbe és az üzletünkbe. A szoftverfejlesztés magas szintő innovációs szakterület. Nem csak a szoftverfejlesztık tudásterülete! Mindannyian kapcsolatban vagyunk, vagy kerülünk vele. Ismerjük meg. A szoftverfejlesztés rendszerként szoftverfejlesztés alrendszerei:

3.1

értelmezhetı,

mely

több

alrendszerbıl

épül.

A

Tervezési alrendszer

A konkrét tervezési munkát összetett, mindenre kiterjedı követelményspecifikáció elızi meg, mely a tervezés alapja. A koncepcionális (logikai) rendszerterv jóváhagyása után történik a részletes (fizikai) rendszerterv összeállítása és jóváhagyása. A tervezési alrendszer a fejlesztési feladat kidolgozásának és elfogadtatásának a szakterülete. A tervezési alrendszerben készül a tesztelési-, a minıségi-, a kommunikációs-, a konfigurációs-, és a költségvetés-terv is.

3.2

Fejlesztési alrendszer

A fejlesztés a tervek megvalósítását jelenti. Algoritmuskészítés, programkódolás, programkövetés (debugging), parametrizálás, próbafuttatás, stb. tevékenységek szerint épül a szoftver. Célszerő ezeket a releváns fejlesztési tevékenységeket azonosítani és teljesítménytényezıkkel ellátni, a méréshez és elszámoláshoz. A fejlesztés többféle fejlesztési módszert ismer és használ. Néha egyidıben. Az egyes módszerek eltérı fejlesztési szakaszokkal, folyamatokkal, tevékenységekkel, mérföldkövekkel számolnak. Célszerő ezt egy fejlesztési tevékenység-katalógusban is jelölni és majd kezelni a kontroll munkában.

3.3

Ellenırzési alrendszer

Az ellenırzés a tesztelési munkafolyamaton (körfolyamat) túl, minıségellenırzést is jelent. A minıséget több aspektusból kell „megfognunk” és irányítanunk.




5./24


A fejlesztési minıség három dimenziója Megfelelıség ISO

IT SERVICE Támogatás

Nyújtás

6 Sigma

CMM Level 5 Fókusz a fejlesztésre

A keresztfunkciós folyamatok felügyelete

A „kipróbálás” módszere a tesztelés. Ekkor ismert bemenı adatokkal próbáljuk ki az alkalmazást, és elıre tudjuk az elvárt eredményt. A teszteléskor a tesztelési tervet használjuk, ami már a rendszertervezéskor elkészült. A tesztelési tervben tükrözıdik a kockázati helyzet. A kockázatokat tartalmazó funkciókat kell alaposan tesztelni. A tesztelés jelentıs költséget okoz és a felhasználóktól is jelentıs többletmunkát vár el. Egy vezetı akkor bízhat az alkalmazásban, ha a tesztelést szakszerően tervezték és a sikeres tesztelést megfelelıen dokumentálták. A tesztelési terv kockázatelemzésen nyugszik. Ehhez felsorolják a szoftver összes funkcióját, majd elemzik az adott funkció kockázatosságát. Azokat a funkciókat kell tesztelni, amelyek kockázatot tartalmaznak. Íme egy példa:

Sorsz.

Tranzakció kódja

Mővelet megnevezése

Kritikus

Tesztelési Teszte- dokumentum kódja lendı Igen

…. 32.

FBL5N

Számla tétel megjelenítés

Nem

33.

FBL6

Számla tétel módosítás

Igen

Igen

34.

FD10N

Számla egyenlegek megjelenítése

Nem

Nem

35.

FD11

Számla elemzés

Nem

Nem

53.

LS01N

Raktári tárhely létrehozása, manuális

Igen

Igen

54.

LS02N

Raktári tárhely módosítása, egyenként

Igen

Igen

55.

LS03N

Raktári tárhely megjelenítése

Nem

Igen

56.

LS04

Üres tárhelyek

Nem

Nem

288.

MI04

Leltár rögzítés

Igen

Igen

289.

MI05

Leltár módosítás

Igen

Igen

290.

MI06

Leltár rögzítés megjelenítés

Nem

Igen

291.

MI07

Leltáreltérés könyvelése

Igen

Igen

….

….

…. Megjegyzés: Sok helyen használt programcsomagról van ez esetben szó. Ezért a lekérdezéseknél azonos adatra csak egy fajta lekérdezés tesztelését tervezik.

A tesztelési terv megléte és az arra alapozott sikeres tesztelés még önmagában nem garancia a megfelelı tesztelésre. Nagyon fontos, hogy a tesztelési tervben az alkalmazás elemi funkciói szerepeljenek. Ez összetett alkalmazásnál igen nagymérető tesztelési tervhez vezet. Az egyes elemi funkciók is tartalmazhatnak különféle lényegesen eltérı gazdasági eseményeket az adatok fajtái szerint. Például az anyagmegrendelési funkció takarhat gyártáshoz szükséges nyersanyagokat, karbantartáshoz szükséges mőszaki anyagokat, rezsi anyagokat stb. Ha minden apró változatában ki akarnánk próbálni egy integrált alkalmazást, akkor több tízezer, néhány százezer esetet kellene tesztelni. Ezek közül az ésszerő kockázatviselésig kell válogatni a lehetséges esetekbıl. Szerzı: Véry Zoltán



6./24


A tesztelés önmagában kockázatos, mert hibás adatok is keletkezhetnek a tesztelés során. Ezért a tesztelést egy külön rendszerben, általában egy külön számítógépen végzik. Az alkalmazás kipróbálása tekintetében a vezetınek ellenırzési feladata van. Azt kell ellenıriznie, hogy a kockázatoknak megfelelı minden fajta kipróbálást elvégeztek a felelısök és a kipróbálás során az alkalmazás megfelelınek mutatkozott. A tesztelésen kívüli megfelelıségi bizonyítások különös esetekben használatosak. Rendkívüli kockázatot jelentı alkalmazásoknál az alkalmazás minden programját sorról sorra átvizsgálhatják (inspekción alapuló kvalifikáció). Egyes iparágakban pedig a validálásnak nevezett eljárás-együttes kötelezı mindazon alkalmazásokra, amelyek az adott iparágban jelentıs kockázatot tartalmaznak. A tesztelés, kvalifikálás és validálás elengedhetetlen háttér tevékenység a vezetı számára. A kockázattal arányos mélységig le nem tesztelt alkalmazást nem szabad használni!

3.4

Irányítási alrendszer

A fejlesztés többnyire projektalapú munkával, több szakember együttmőködésével bonyolódik. A fejlesztést a projektvezetı irányítja. Több projektirányítási módszert ismerünk (lásd a következı fejezetben) és alkalmazunk - akár egyidıben. A fejlesztendı termék és a fejlesztési munka komplexitása, terjedelme, idıkorlátok szerint eltérı módszertant használ(hat)unk. Ez azt jelenti, hogy új és újabb módszertanok elsajátítása és frissítése többletráfordítással jár. A fejlesztési részfeladatok irányítását azok az önszervezıdı szakmai team-ek végzik, akik felelısek a szoftver komponensek és/vagy a komponensek összeszerelési, integrálási folyamataiért, illetve a termékért. A projektvezetı a projekt folyamatait, a változásokat, a határidık betartását, a projekt termékek és szolgáltatások minıségét és költségkeretet (budget) menedzseli. Kiszolgáló munkatársa: a controller pedig, üzemgazdasági-, pénzügyi-, kalkulációs-, felügyeleti-szabályozási szakértéssel támogatja. A szoftverfejlesztés minıségi követelményeinek specifikálása, minıségbiztosítása és minıségellenırzése is tartozhat a controllerhez. Amennyiben rendelkezik ilyen képzettséggel és jogosítványokkal. A controller koordinálja – akár több projekt számára - a költségvetés készítés folyamatot. Követi a tevékenységeket és változásokat. Szükség esetén elemzést, kalkulációt készít a változások pénzügyi következményeirıl, illetve a változások teljesítmény, kapacitás és a költség kihatásairól. Jelentéskészítési és jelentés-értékelési (kommentálási) tevékenységgel segíti a projektvezetıt és teameket. Az együttfutó fejlesztési projektek egymás közötti teljesítményátadásait és a közös erıforrások beszerzését is ı koordinálja. A szoftverfejlesztés egészének pénzügyi-üzemgazdasági szakértıje illetve teljesítmény-, kapacitás-, kompetencia-tényezık kontrollıre. A szoftverfejlesztés irányításialrendszerének tipikus szereplıje.

3.5

Implementációs alrendszer

A projekt eredményei, a szolgáltatások, a komponensek, a félkész- és késztermékek kerülnek átadásra. Az implementációs alrendszer készíti elı az átadást, mely a validálással kezdıdik. A validálás a felhasználó követelményeknek való „megfelelıség”. Ez azt jelenti, hogy nem csak jól mőködik a szoftver, hanem úgy mőködik, ahogy a felhasználó elvárja és a környezetében is megfelel minden követelménynek. (pl.: integrációs-, vagy terhelés-követelmények, stb.)




7./24


Megfelelıség (Compliance) Az üzletvitelben egyre fontosabbak az ellenırzött folyamatok. A számítógépes alkalmazásokban is egyre több ellenırzési funkció van. Ennek lényeges eleme a vezetıi, vagy a vezetı nevében végzett ellenırzés. Az elkészült szoftveren, például az alkalmazáson túl magát az üzleti folyamatot is ellenırizni kell speciális esetekben. A Sarbanes-Oxley törvény elıírja például, hogy amerikai vállalatoknak és az amerikai tızsdéken szereplı vállalatoknak olyan ellenırzési rendszert kell kiépíteni és folyamatosan mőködtetni, amely biztosítja a pénzügyi beszámolók megfelelıségét. Az ellenırzött rendszer, az ellenırzött alkalmazás fogalma két dolgot takar: - maga az alkalmazás és a számítógépes rendszer olyan ellenırzött módon készült, amely biztosítja a követelmények szerinti folyamatos mőködést, - az alkalmazásba (és a számítógépes rendszerbe) olyan úgynevezett folyamatba épített ellenırzéseket terveztek és használnak, amelyek biztosítják az adatok megfelelıségét is. Olyan ellenırzött szoftvert, alkalmazást kell építeni és mőködtetni, mikor a cég és a vezetı bízhat az elıállított és közzétett adatokban. A validációt a telepítés és próbaüzemeltetés követi, amit az implementációs alrendszer személyzete végez, szakértıi felügyelnek. A telepítéssel nem fejezıdött be a fejlesztés, csak lezárult. Az életciklus-szemlélet azt követeli meg a fejlesztéstıl, hogy folyamatosan informálódjon az üzemeltetésrıl, a továbbfejlesztés készültségével. Az üzletvitel és az üzleti környezet változásai jelentıs tovább-fejlesztést indukál. Az életciklus szemlélető fejlesztés megelızi a továbbfejlesztési igényeket, kéréseket.

3.6

Információs- és dokumentációs alrendszer

A fejlesztési program és projekt-portfoliók olyan adatokat, adatbázisokat feltételeznek, mellyel átláthatóvá, befolyásolhatóvá - és ezáltal irányíthatóvá válnak. A projektirányítási információs- és dokumentációs rendszerek (PSA, EPM, stb.) teljeskörő megoldást nyújtanak az adatok, információk és digitális tartalmak rendszerezésére, kezelésére és hálózati eléréséhez. Többnyire az ERP rendszerek részeként, vagy azokkal együttmőködésben.

4. Alkalmazott szoftverfejlesztési módszerek és eszközök

Outputs

Inputs

Code & Test Cycle

Ez nem szoftverfejlesztési szoftverkészítési munka!

módszer,

hanem

végtelen

Ahhoz, hogy módszeressé, átláthatóvá és befolyásolhatóvá tegyük a fejlesztést, ismernünk kell az alkalmazott fejlesztési módszereket, melyek meghatározóak a számunkra. Az alkalmazott folyamatokat, tevékenységeket magukba foglalják. A módszertanok elemei, összetevıi, szereplıi és moduljai a fejlesztés-controlling rendszer számára alapul szolgálnak. Úgy a Szerzı: Véry Zoltán



8./24


felelısség-felügyelet (költséghelyi elszámolás), mint az értékteremtés-felügyelet vonatkozásában. A teljesítmények és a ráfordítások mérésekor és elszámolásakor. Az alábbiakban összefoglaljuk a legelterjedtebb szoftverfejlesztési metodikákat:

4.1

Teljes életciklus szemlélet: Vízesés Modell

A teljesség kedvéért szerepeltetjük. Ma már nem használják, mert változott a vevık, a megrendelık környezete, ritmusa és igénye.

4.2

Teljes életciklus szemlélet: V-MODELL

A módszert több német egyetem fejlesztette ki. Ma már széles körben használják a német nyelvő területeken: üzleti vállalkozások és államigazgatási szervezetek egyaránt. V-MODELL alapséma Felhasználói Követelmények definíció

Validálás

SzoftverKövetelmények definíció

Rendszer tesztelés

Architektúra tervezés

Integrációs tesztelés

Részletes tervezés

Komponensek tesztelése

Kódolás




9./24


V-MODEL GBV1 minta

Javaslat: Pro A gyakorlatra épül Fentrıl le (top down) tervez Lentrıl fel (bottom up) valósít meg Nagyon részletesen kidolgozott

Kontra A megtanulása idıbe telik

Sok az adminisztrációs munka

A V-Model több változata épült ki és mőködik fıleg német nyelvterületeken. A rendszer a következı modulokat tartalmazza: Rendszerfejlesztés (System Development, SD) modul. Minıségbiztosítás (Quality Assurance, AQ) modul. Szoftverkonfiguráció-kezelés (Configuration Management, CM) modul. Projektmenedzsment (Project Management, PM) modul. Ez lehet a PMI PMBOK vagy a Célvezérelt projektmenedzsment (GDPM2) módszertan akár.

1 2

http://en.wikipedia.org/wiki/V_model www.gdpm.hu


http://www.informatik.uni-bremen.de/uniform/gdpa/

http://www.v-modell-xt.de



10./24


4.3

Célvezérelt projektmenedzsment (GDPM)

A feladat kisebb mérete, összetettsége esetén a szoftverfejlesztéshez olyan módszertant válasszunk, mely megkönnyíti a munkánkat. A GDPM ilyen eszköz és módszer. A „Mérföldkıtervezés” során az egyes projekt mérföldkövekhez rendelhetünk részeredményeket, eredményeket, azaz olyan outputokat, melyekkel követhetıvé és értékelhetıvé válik a megrendelık számára is a szoftverfejlesztési munka.

Átfogó célok meghatároz. A koordináció elvei Az erıforrások elosztása Eredmény kontroll

Steering Committee

PROJECT DEFINITION

Mérföldkı tervezés A felelısség kijelölése A célok ütemezése Változás kontroll

Project Manager

Contact

Tevékenységek listája A szerepkörök kijelölése Tevékenységütemezés Tevékenység kontroll

Project Team

Global Reporting

GlobalPlanning & Organising

Rolling wave Planning

Detail Reporting

DetailPlanning & Organising

MIKOR?

KINEK?

MIT?

„Milestone Plan”

„Responsibility Chart”

„Activity Schedule” & „Progress Report”

A GDPM módszertan részletes megismerésére és elsajátítására külön tananyagot és kurzust kínálunk. (ld. www.gdpm.hu, www.bmsinformatika.hu)




11./24


4.4

AGILIS fejlesztési módszerek

A gyorsan változó üzlet, gyors megoldásokat vár a fejlesztıktıl. Ezen követelmény teljesítéséhez alkották meg az „agilis” szoftverfejlesztési3 módszertanokat, melyek közül a DSDM és a SCRUM módszertant mutatjuk be áttekintı jelleggel.

4.4.1 Dinamikus Rendszerfejlesztési Modell (DSDM)

A DSDM alkalmazásfejlesztéshez, illetve alkalmazás bevezetéshez készült. A DSDM alapelvei •

A DSDM fı célja, olyan rendszer fejlesztése, amelyik a jelenlegi üzleti igényeket elégíti ki. A cél nem egy tökéletes üzleti rendszer szállítása, amely minden elképzelhetı igényt kielégít, hanem a projekt létfontosságú céljainak elérése.

•

Egyetlen rendszert sem lehet elsıre tökéletesre megírni. A rendszerfejlesztés során a funkcionalitás 80 százalékát meg lehet írni a tökéletes rendszer kifejlesztéséhez szükséges idı 20 százalékában. Az a 20 százalék, ami a mőködı és a tökéletes rendszer között van, gyakran okozza a projektek kicsúszását a határidıbıl és a költségvetésbıl. A DSDM célja éppen ezért a 80 százaléknak az elıállítása.

•

A projektnek a határidın és a költségvetésen belül kell végzıdnie, jó minıségő termék elıállításával.

•

A rendszerrel szemben támasztott követelményeknek tartalmaznia kell valamelyes rugalmasságot, a fenti elvekbıl következıen.

3

http://en.wikipedia.org/wiki/Agile_software_development




12./24


•

A DSDM-ben minden lépésnek addig kell eljutnia, hogy a következı lépést lehetıvé tegye, egy centivel se tovább. Így a következı lépéssel a lehetı legkevesebbet kell várni, és a rendszer minden lépésben fejlıdni fog.

•

A kommunikáció a projekt összes résztvevıje között elengedhetetlen követelmény a projekt sikeréhez.

•

Az ügyfél bevonása nélkül ebbıl kifolyólag lehetetlen sikeres projektet végrehajtani.

•

A csapatnak felhatalmazást kell kapnia olyan döntések meghozására, amik fontosak

•

A DSDM tartalmaz projekt menedzsment technikákat, és szoftverfejlesztési technikákat

lehetnek a haladás érdekében. is. •

A DSDM használható létezı rendszerek továbbfejlesztésére is, sıt nem IT-vel kapcsolatos, hanem inkább üzleti változás-jellegő projektekben is.

A DSDM használatának feltételei A DSDM sikeres alkalmazásához szükség van néhány feltételre. Elıször is arra, hogy a csapat tagjai között, a leendı végfelhasználók között, és a felsıvezetés között interaktív, kétirányú kapcsolat legyen. Ez azért kell, hogy elkerülhetık legyenek azok az ismert hibák, amik

a

felsıvezetés

motivációjának

hiányából

erednek,

és/vagy

a

felhasználó

közremőködésének hiányából adódnak. Másodszor is, a projektnek felbonthatónak kell lennie, vagyis lennie kell értelmes dekompozíciónak. A DSDM iteratív, inkrementális technikái csak elkülönülı részekre mőködnek igazán jól. Azt is meg lehet tenni, hogy a nagy projekt szétesik sok kis alprojektre, amelyek egymástól függetlenül használnak DSDM-et, vagy valami mást, és a nagy projektet kezeljük DSDM-mel. Harmadszor, a követelményeket egyértelmően meg kell határozni, és prioritás szerint sorba kell rendezni. Ha egy projekt ennek a három dolognak nem felel meg, akkor kevésbé célszerő DSDM-et alkalmazni. Például túlságosan bonyolult projekteket, amik nem esnek szét független részekre, nem lehet iteratívan fejleszteni. Hasonlóképpen, olyan projektek, amelyeknek nincsenek egyértelmően meghatározott céljai, következésképpen nem is lehet ezeket prioritás

szerint

költségvetésbıl

sorba

rendezni,

kicsúszni,

és

jó

eséllyel

fognak

ezen

a

minden

DSDM

létezı sem

határidıbıl tud

és

segíteni.

Ezenfelül vannak olyan projektek, amelyeknek mindennél fontosabb célja a biztonságos mőködés, vagyis olyan alkalmazás készítése, ami minden körülmények között rendelkezésre áll. Ezek tipikusan emberélettel kapcsolatos alkalmazások. Az ilyen projektekben az égvilágon mindent le kell tesztelni, és a legkisebb hibát is addig kell csiszolni, amíg el nem tőnik, ez pedig ellentmond annak, hogy a DSDM célja nem a tökéletes szoftver elkészítése, hanem egy elfogadhatóan jó szoftver készítése határidın és költségvetésen belül. Ugyanebbıl az okból nem alkalmas a DSDM újrahasznosítható komponensek és hasonlók készítésére sem, ahol az 'elég jó' nem elég jó, hanem csak a tökéletes felel meg, hiszen nem lehet elıre tudni, hogy milyen alkalmazás mit fog elvárni a komponenstıl.




13./24


A DSDM szakaszai A DSDM három szakaszból áll, a projekt-elıtti szakaszból, a projekt-szakaszból, és a posztprojekt szakaszból. A projekt-szakasz a legbonyolultabb, ennek 5 kapuja van, amelyek iteratívan, lépésrıl-lépésre közelítik meg a projekt célját. A projekt-elıtti szakasz A projekt-elıtti szakaszban elıször is meg kell határozni a lehetséges projekt-jelölteket, meg kell szerezni a támogatást a projekthez, és ki kell alakítani a projekt iránti elkötelezettséget minden résztvevıben. Azzal, hogy ezeket a dolgokat az elején tisztázzuk, sok fejfájástól kíméljük meg magunkat a késıbbiekben. A projekt életciklusa A fenti ábra mutatja a projekt kapuit a második szakaszban. Az elsı két kapu egymás után következik, és egymást egészítik ki. Miután ezeket elhagyjuk, megkezdıdik a rendszer iteratív és inkrementális fejlesztése, a Funkcionális modell, Tervezés és építés iteráció, és Megvalósítás kapukon keresztül. Elsı kapu: a Megvalósíthatósági Tanulmány (Feasibility Study) Ezen a kapun azt kell megvizsgálni, hogy a projekt megvalósítható-e DSDM segítségével. A már említett elıfeltételek meglétét kell megvizsgálni, olyan kérdéseken keresztül, mint például „Ez a projekt alkalmas-e az üzleti igény kielégítésére?”, „Mik a legkomolyabb kockázatok

és

a

legfontosabb

célok?”.

A

legcélszerőbb

erre

a

workshop-ok,

mőhelytalálkozók szervezése. A végeredmény pedig a Megvalósíthatósági Tanulmány és a Megvalósítható Prototípus, amelyek alátámasztják a projekt megvalósíthatóságát. Ezt ki lehet bıvíteni még egy globális Körvonalas Tervvel, ami a projekt hátralévı részét írja le körvonalakban, és egy Veszélynaplóval, amelyik a legfıbb kockázatokat tartalmazza. Második kapu: az Üzleti Terv (Business Study) Az üzleti terv a Megvalósíthatósági Tanulmány kiterjesztése. Miután kiderült, hogy a projektet meg lehet valósítani DSDM segítségével, meg kell vizsgálni, hogy milyen üzleti eljárásokra van szükség, kik a felhasználói csoportok, és milyen igényeik és kívánságaik vannak. Itt is a mőhelytalálkozók a leghasznosabbak, ahol a különbözı résztvevık összeülnek, és megbeszélik a rendszert. Ezekbıl az ülésekbıl áll össze a végsı igénylista, amelynek fontos jellemzıje, hogy az igények prioritással együtt kerülnek rá. Az igények prioritására a „Mükéné” rendszert javasoljuk. Ez négy csoportba sorolja az igényeket: Muszáj; Kéne, ha lehet; Nem ártana, ha belefér; Nem kerül be, de majd késıbb esetleg. Ezekre a prioritásokra alapozva készül el a fejlesztési terv, ami iránymutatóként szolgál a projekt

teljes

idıtartama

alatt.

A

terv

kialakításának

fontos

része

az

idıkeretek

megállapítása. A DSDM sikere jórészt itt dıl el, hiszen a végsı cél az, hogy az idıkereteken Szerzı: Véry Zoltán



14./24


és a költségvetésen belül maradva sikerüljön elég jól megközelíteni a célt, a helyes idıkeretek meghatározása tehát nagyon fontos. Lehet készíteni architektúra-tervet is, ami szintén iránymutatóként szolgálhat a fejlesztés során. A kimenet pedig annak az üzleti területnek a meghatározása, amelyet a projekt le akar fedni, továbbá egy rendszerterv és fejlesztési terv, amelyek együtt határozzák meg a fejlesztés legfontosabb lépéseit és kapuit. Ezen két dokumentum alapja pedig a prioritásos követelménylista, amely a Mükéné-elv alapján van sorba rendezve. A Veszélynaplót is frissíteni kell, mert jó eséllyel változnak a projektre leselkedı veszélyek is. Harmadik kapu: Funkcionális Modell Iteráció (Functional Model Iteration) Az igényeket, amelyeket az elızı lépésben összegyőjtöttünk, most funkcionális modellé alakítjuk. Ez a modell egy mőködı prototípusból, és modellekbıl áll. A prototípus-készítés fontos része ennek a lépésnek, mert ettıl függ a felhasználók bevonása a projektbe. A kifejlesztett prototípusokat meg kell néznie minden érintett felhasználói csoportnak. A minıség biztosításának érdekében a DSDM minden iterációs ciklusában szükség van tesztelésre. A funkcionális modell négy további lépésre bontható: •

A

funkcionális

prototípus

meghatározása:

Meg

kell

határozni,

hogy

milyen

funkcionalitása legyen a prototípusnak, ami majd az iteráció végén létrejön. •

Ütemterv: ki kell egyezni, hogy mikor és hogyan fogjuk kifejleszteni a prototípust.

•

A funkcionális prototípus létrehozása.

•

A prototípus átnézése: ellenırizni kell a kifejlesztett prototípust. Ez történhet a végfelhasználók által, és/vagy a dokumentáció átnézésével.

Mindennek az eredménye egy Funkcionális Prototípus, meg egy Funkcionális Modell, amelyek együtt képviselik azt a funkcionalitást, amit ebben az iterációban ki lehetett fejleszteni,

és

készen

állnak

a

felhasználói

tesztelésre.

Aztán

frissíteni

kell

a

Követelménylistát, ki kell törölni, ami elkészült, és a maradék igények prioritását újra kell gondolni. Negyedik kapu: Tervezési és Építési Iteráció (Design and Build Iteration) A lényege ennek a kapunak, hogy a komponenseket, amik az elızı szakaszban létrejöttek, integrálni lehessen egy rendszerbe, amelyik a felhasználóknak megfelel. Itt kell gondolni a nem funkcionális jellegő követelményekre, amelyeket a rendszerrel szemben támasztunk. A tesztelés ennek a kapunak is nélkülözhetetlen része. Ez a kapu is négy lépésre bontható: •

A tervezési prototípus meghatározása: Meg kell határozni azokat a funkcionális és nem funkcionális követelményeket, amelyeket a tesztrendszerrel szemben támasztunk.

•

Ütemterv:

ki

kell

egyezni,

hogy

mikor

és

hogyan

történik

a

tesztrendszer

megvalósítása. •

Tervezési prototípus elkészítése: Olyan rendszert kell készíteni, amelyet bátran oda lehet adni a végfelhasználóknak napi használatra.




15./24


•

A tervezési prototípus átnézése: le kell ellenırizni a kész rendszer helyességét. A tesztelés és az átnézés a legfontosabb.

A végeredmény egy Tervezési Prototípus lesz, amelyet a végfelhasználók teszteltek, és Tesztelt Rendszer címszóval mehet tovább a következı kapura. Ötödik kapu: Bevezetés (Implementation) A

bevezetés

során

a

tesztelt

rendszert

a

dokumentációval

együtt

átadjuk

a

végfelhasználóknak, és betanítjuk a további végfelhasználókat. A kész rendszert átnézzük, hogy megfelel-e azoknak a követelményeknek, amiket a projekt elején állapítottunk meg. Ezt a kaput is négy lépésre lehet bontani: •

Felhasználói jóváhagyás és útmutatás: A végfelhasználók jóváhagyják a rendszert, és közösen létrehozunk egy útmutatást, hogy hogyan kell használni a rendszert, mit tud, és mire való.

•

Felhasználók betanítása: a majdani végfelhasználókkal meg kell ismertetni a rendszert.

•

Bevezetés: A tesztelt rendszert feltelepítjük a végfelhasználó telephelyén.

•

Az üzleti terület átnézése: megnézzük a bevezetett rendszer hatását az elején meghatározott üzleti területre. Ennek végeredményétıl függıen a projekt vagy átkerül a poszt-projekt szakaszba, vagy egy korábbi kapura kerül vissza, további fejlesztés céljából.

A végeredmény egy Bevezetett Rendszer a végfelhasználók munkahelyén, és részletes felhasználói dokumentáció a rendszerrıl. Harmadik szakasz: poszt-projekt A poszt-projekt szakasz célja, hogy biztosítsa a rendszer hatékony mőködését. Ez karbantartással, javításokkal és bıvítésekkel érhetı el, a DSDM elveknek megfelelıen. Akár új projekteket is lehet indítani a létezı rendszer kibıvítésére, vagy új rendszerkomponens kifejlesztésére.




16./24


4.4.2 SCRUM Modell A SCRUM4 menedzsment jellemzıi •

Kell egy prioritás szerint rendezett lista az élı, felgyülemlett feladatokról.

•

Ebbıl a listából kell egy nagyon szigorúan meghatározott részlistát készíteni egy rövid nekifutással, amit sprintnek nevezünk.

•

Kell egy rövid megbeszélés mindennap, amit SCRUMnak nevezünk, ahol kiderül, hogy mi készült el, mi lesz készen a közeljövıben, és mik a problémák.

•

Kell egy rövid tervezési „találka”, ahol az aktuális sprintre vonatkozó feladatokat kell kitalálni.

•

Kell egy szívdobbanásnyi visszatekintés, amikor a csapattagok visszatekintenek a hátuk mögött lévı sprintre.

A SCRUM-oknál van egy SCRUM-Mester, akinek az a fı dolga, hogy elhárítsa a csapat útjában lévı akadályokat, amik meggátolják, hogy a projekten dolgozzanak. A SCRUM Mester nem a csapat fınöke, lévén a csapat jobbára önszervezıdı, de pufferként funkcionál a csapat és a destabilizáló hatású befolyások között. A SCRUM azzal segíti elı a csapatok önszervezıdését, hogy bátorítja a kommunikációt a csapat tagjai között, meg egyáltalán mindenki között, aki csak a projektben érintett. A SCRUM egyik fı alapelve, hogy alapvetıen gyakorlati jellegő kihívásokat nem lehet pusztán tekintély-alapon megoldani. Ezért a SCRUM elfogadja, hogy a problémát nem mindig lehet teljesen megérteni, vagy meghatározni, ehelyett inkább a csapat teljesítményét kell maximumig fokozni, hogy aztán a csapat agilisan és rátermetten oldja meg ezeket a problémákat. A SCRUMnak nincs 'receptje' a sikeres projekt menedzsmentre, mert nem elıre meghatározott elıírásokban látja a projekt sikerét. A SCRUM inkább egyfajta hozzáállás. SCRUM Sok szervezet van, amelyik igencsak ellenáll a lentrıl jövı módszertani kezdeményezéseknek. A SCRUM azonban könnyen bevezethetı „fő alatt” is. Ehhez három alapvetı dologra van szükség: •

Ütemezz be egy demo bemutatót az ügyféllel, mostantól számított 1 hónap múlva.

•

A csapat készítse fel a szoftvert a bemutatóra - írja meg, amit kell, semmi screenshot.

•

A bemutatott programról kérd ki az ügyfél véleményét, aztán ugorj a lista elejére, és a csapat eme vélemény alapján fejlessze tovább a szoftvert egy újabb demora.

4

„scrum” angol szó, jelentése: közelharc, összecsapás, viaskodás




17./24


Ezzel az eljárással, ami egyszerő és a józan észen alapul, a SCRUM módszerének a lényegét megvalósítottuk, és lehet rá építeni. Alkalmazkodó projektmenedzsment Manapság nem túl gyakori, hogy egy szolgáltató megmondja a projekt jellemzıit és követelményeit elsıre. Sokkal gyakoribb az inkrementális szállítás, vagy az, hogy az ügyfél nem veszi át az eredményt. Viszont senki sem akarhatja megkövezni az ügyfelet azért, mert nincs tisztában azzal, hogy pontosan mire van szüksége. Lehet, hogy az ügyfél nem is végfelhasználó. Az ilyesfajta sokszereplıs helyzetekben gyakran csak agilis módszerekkel lehet sikerre vinni egy projektet, mert hiába határozta meg az ügyfél hajszálpontosan, hogy mi kell neki, ha a végfelhasználó közbeszól, és mindent megváltoztat. Néhány tipp a SCRUM-ból: •

Az ügyfélnek valamilyen formában részévé kell válnia a fejlesztıcsapatnak.

•

Gyakori közbülsı kiadások KÖTELEZİEK.

•

A fejlesztıcsapatnak kell kockázattervet készítenie, minél gyakrabban.

•

Napi szintő megbeszéléseket kell tartani a helyzetrıl. o

Mit csináltál meg tegnapról?

o

Mit tervezel holnapra?

o

Van-e bármi probléma?

•

Az egyes modulok tervének és a modulok összefüggéseinek MUSZÁJ átláthatónak lenni.

•

Ha valamelyik tulajdonsággal baj van, nem szabad a programot kiadni.

•

Gyakran kellenek olyan találkozók, amikre MINDEN résztvevı eljön.

•

Semmilyen problémát nem szabad a szınyeg alá söpörni. Senkit nem szabad

•

Energikus munkahely, és hasznosan töltött munkaórák ELENGEDHETETLENEK. A

megbüntetni egy probléma miatt. „túlóra” nem szükségképpen jelent „túlmunkát” is. A napi találkozók ütemezése A legjobb pillanat a napi találkozókra ebéd után van. A reggeli találkozó nem jó ötlet, különösen olyan cégeknél nem, amelyek flexibilisen dolgoznak. Általában ezek a találkozók nem tartanak sokáig, úgyhogy tarthatunk „állófogadást” is, amikor mindenki feláll, és odasétál egy táblához, aztán ott beszélgetnek egy kicsit. Az ebédszünet alatt az emberek általában úgyis megbeszélik az élet nagy dolgait, úgyhogy az ebéd utáni beszélgetéseket könnyebb a munkára koncentrálni, és az emberek is jobban oda tudnak figyelni. Ráadásul miután mindenki mögött fél nap munka áll már, ezért az eszük is jobban rááll addigra a feladatra. Kristálytiszta elvek Kristály: emberközpontú, kommunikációban erıs, kicsiket szállít, ön-adaptálódó.




18./24


Az alábbi központi elemekbıl áll: •

Kezdd azzal, hogy jól megnézed magadnak a projekt tagjait, a kulturális hátterüket,

•

Használd valamelyik agilis módszertant, hogy eldöntsd, mit kell tenni, és mit kell

faggasd ki ıket négyszemközt. elkerülni. •

Szedd szét a projektet elkülönülı, független részekre (partíciókra).

•

Határozd meg a lehetı legkevesebb szabályt, ami nélkül abszolút nem haladna a projekt elıre.

•

Határozd meg, mi az elképzelhetı minimum, amivel elı kell állni a projekt végén.

•

1-4 hónapig tartó lépésekben haladj elıre.

•

Minden lépés közepén és végén tarts visszapillantás-jellegő találkozókat, határozd meg, hogy mi mőködik, és mi nem. Készíts egy 3 oszlopos táblázatot, az oszlopok fejléce legyen rendre Elkezdeni, Abbahagyni, Folytatni legyen. Így finomítsd az eljárást.

Ehhez igazából 3 dologra lesz elıre szükséged, amiket némi utánajárással a NET-rıl, vagy könyvekbıl lehet összeszedni: •

Alapvetı technikák a projekt-interjúkhoz.

•

Alapvetı technikák az eredmények meghatározásához

•

Alapvetı technikák a visszapillantó-találkozókhoz.

Egy képzeletbeli párbeszéd, ami segít megvilágítani, hogy mirıl szól a Kristálytiszta gondolkodásmód: •

Én: Az ön-alkalmazkodás része a Kristálynak.

•

Jómagam: Igen, de egy másik, alapvetıbb elvbıl következik: ”Azok tudják legjobban, hogy hogyan kell dolgozni, akik a munkát ténylegesen végzik.”

•

Én: Igen, de ebbıl következik: „Ha a munkát végzık megkapják azt a munkát, hogy határozzák meg, hogyan lehet a legjobb dolgozni, akkor ezt a munkát is ık fogják tudni legjobban elvégezni.”

•

Jómagam: Igen, de ennek elıfeltétele, hogy az legyen a céljuk, hogy a munka el legyen végezve.

Ugyanakkor az is igaz, hogy az ön-alkalmazkodás nem csak alulról jöhet, egy rátermett menedzser is megtalálhatja a módját annak, hogy a munkavégzés módja alkalmazkodjon a körülményekhez. Az is megtörténhet, hogy bár az embereknek nem az a célja, hogy a munka el legyen végezve, de rá vannak kényszerítve, és viszont akkor már jobban megéri a lehetı leghatékonyabban dolgozni. Olyan is van, hogy ık ugyan szeretnék, ha a munka el lenne végezve, de nem áll rendelkezésükre minden, ami a munka leghatékonyabb kialakításához kell - jogkör, információ, tapasztalat, vagy erıforrás is hiányozhat ehhez. A Kristály lényege tehát egyfajta decentralizált ön-alkalmazkodás, egy közös cél érdekében.




19./24


5. A szoftverfejlesztés minıségbiztosítása Az ISO mellett számtalan szoftverfejlesztést támogató minıségbiztosítási és minıségellenırzési módszert használnak: Az egyes módszerek alkalmazása az USA-ban, a távol-keleti országokban és Európában eltérıek lehetnek. Az alábbi ábra áttekintést nyújt ezen a téren:

A három legelterjedtebb minıségbiztosítási rendszer az ISO 9000, a Capabilitiy Maturity Model (CMM) és a Six Sigma, melyek nem kizárják, hanem adott esetben feltételezik egymást.

A szoftverfejlesztés minıségbiztosítása folyamatjellegő, míg a szoftver - mint termék minıségbiztosítása tárgyra vonatkozó követelményrendszer és módszertan.

5.1

CMMI – minıségvezérelt projektmenedzsment

A CMMI (Capability Maturity Model Integration) minıségvezérelt projektmenedzsment módszer – amelynek alkalmazása az USA-ban már az 1990-es évek óta alapvetı elvárás a szoftverfejlesztı cégekkel szemben - több szinten értelmezhetı az alábbiak szerint:




20./24


CMMI szintek értelmezése Kezdetleges

(Nincs)

Menedzselt

Definiált

Kvantitatívan menedzselt

Optimalizált

1. Tervezés

4. Integrált 8. Kvantitatív projekt mgt projekt mgt 2. Monitoring és kontroll 5. Integrált csapat 3. Szállító mgt

6. Kockázatkezelés 7. Integrált szállító mgt

Minıségvezérlés alapja

A projekt tervezett költségkerete és az elvárt átfutási idı függvényében kell mérlegelnünk, hogy a minıségvezérlést melyik szinten valósítjuk meg. A minıségvezérlés legmagasabb foka, amikor az optimalizálást folyamatos méréssel, elemzéssel és változáskezeléssel végezzük, melynek feltételeit a projekt során biztosítjuk.

5.2

Six Sigma (6б)

A folyamatképesség jellemzık tervezését, követését és ellenırzését: a Six Sigma nevő minıségirányító rendszer és módszertan támogatja hatékonyan, mely 5 fázisból épül: • • • • •

Definíciós fázis Mérés fázis Analízis fázis Megvalósítási fázis Kontroll (ellenırzés) fázis

A folyamat minıségi jellemzıinek „sávban tartásával” irányítjuk a tervezési, kivitelezési és kontroll munkát. Az alábbi ábrán ezt követhetjük.




21./24


6. Rendszer- és szoftverfejlesztési controlling Ahhoz, hogy átlássuk és befolyásoljuk a fejlesztési folyamatokat, mérnünk kell a szellemi teljesítmény leadás mértékét. Ezt szakértıi órában tudjuk megtenni és a heti- vagy havi munkalapon erıforrásonként rögzíteni. Lásd a következı táblázatot:

Erıforrásonként és tevékenységenként heti (vagy napi) tényráfordításokat. A fejlesztési tevékenységek standardizáltak.


tagolásban

követhetjük



a

22./24


Szellemi tevékenységek ráfordításai Heti tény összesen

A fenti jelentést a heti (szellemi) teljesítményelemzéshez és vezetıi ellenırzéshez használjuk. A teljesítmények mértéke és szerkezete alapot szolgáltat a vezetı irányító, befolyásoló tevékenységéhez.

Projektkövetı jelentés Terv – tény – várható aspektusban

Célszerő idıközönként (hetente vagy dekádonként) a kiemelt projektekre – melyek magas prioritással szerepelnek a fejlesztési programokban és portfolióban – azt a hagyományos controlling jelentést elkészteni, mely világos képet nyújt a vezetı számára, a projektek elırehaladásáról, a tervhez mért eltérés mértékérıl és a befejezésig várható ráfordítások mértékérıl, mely talán a legfontosabb irányítási információ. A controlling jelentési rendszert célszerő úgy kialakítani, hogy minden vezetı csak releváns információkat kapjon (ne számtemetı táblázatokat) idıszakosan és idıszakok között akkor, ha jelentıs változások következtek be, amirıl a vezetınek tudnia kell számszerően is. A jelentések tartalma és szerkezete relatív állandó és változó. Célszerő minden vezetınek „testre szabott” Jelentési füzet-t (jelentés-köteget) kialakítani és eljuttatni. A fejlesztési munka tervezése, megvalósításának követése, folyamatos értékelése, a vezetık önformációkkal való ellátása (jelentések készítése és kommentálása) illetve a céloktól való eltérések (tervSzerzı: Véry Zoltán



23./24


tény=eltérés) esetén a visszacsatolás (intézkedések) tipikus controller feladatok. A kontroll (irányítási) tevékenységeket maga a vezetı is végezheti, végzi adott esetben. Például a projektvezetı. Az alábbiakban bemutatunk egy jelentési mintát, mely mintául szolgálhat. Vezetıi jelentés (A) Célszerő egy vezetıi jelentés-füzetet összeállítani, melyben 8-10 jelentést helyezünk el. Az egyes jelentések, legyenek releváns információtartalmúak és segítsék a vezetıi döntéseket, felismeréseket, ne „számtemetık” és ne „diagramlátványosságok” legyenek. A jelentésen hagyjunk helyet a kommentároknak, észrevételeknek, javaslatoknak is.

---




24./24

IT Controlling tanfolyam. Az informatikai fejlesztés controllingja

Recommend Documents