Projekt koordinációs eljárás a Megrendelő és a Vállalkozó között
Dr. Molnár Bálint PhD, műszaki informatika Egyetemi docens, Budapesti Corvinus Egyetem Tudományos főmunkatárs, ELTE
1. Koordinációs eljárás A projekttervben meghatározott projekt teamek hetente egyeztető megbeszélést tartanak, melyen mindkét fél döntési jogosultsági szinten képviselteti magát. A megbeszélésről jegyzőkönyvet vesznek fel, mely tartalmazza az elfogadott szükséges intézkedéseket, valamint a project előrehaladására vonatkozó meghatározó jellegű információkat. Szükség esetén projectterv módosításra javaslatot tesz és szükség esetén értesíti a szerződésért felelős személyeket. A munkálatok jellegétől függően ezen egyeztetés írásban is megtörténhet oly módon, hogy a vállalkozó a project előrehaladásáról írásos beszámolót készít. Két project-megbeszélés között a szakmai és informatikai képviselők folyamatosan kapcsolatot tartanak A megrendelő projektirányító testülete: Elnök Vezető felhasználó Vezető informatikai szakember Megrendelői oldal képviselője Felhasználói koordinátorok
Informatikai koordinátor
2. Projektszervezet vázlata Vállalkozó projekt irányító testülete
Megrendelő projekt irányító testülete Vezető felhasználó
A testület elnöke
Vezető informatikai szakember
Gazdasági felelős Kapcsolattartó
Vállalkozó felelős
Vezető informatikai
vezetője
szakember, a fejlesztők irányításáért felelős személy
Vezető felhasználó
A testület elnöke
Vállalkozó
felelős
vezetője
Vezető informatikai szakember
Megrendelői oldal képviselője Projekt biztosító
Külső szakértő
csoport Felhasználói koordinátor + Informatikai kordinátor
Adminisztratív
Felhasználói összekötő /
koordinátor
1. ábra Projekt szervezet felépítése
Felső vezetés
Fejlesztési vezető (Projektvezető) (Egy személyi felelős a projektért)
Tanácsadó, szakértő
Informatikai ellenőrzés, audit Képzés, oktatás Minőségbiztosítás
Megrendelő
Változáskezelés
Kockázatkezelés
Fejlesztő
Projekt
2. ábra Projektet körülvevő egyik lehetséges szervezeti felépítése
Program felelős Program vezető
Szervezeti változások Tervezési felelős felelőse
Program igazgató Program támogatócsoport
Projektvezetőségek
Projektvezetők
Projekt biztosító csoport
Projekt támogatócsoport
Fejlesztő csoport vezetők
3. ábra Fejlesztési program lehetséges szervezeti felépítése
3. Projekt vezetés ökölszabályai 1. szabály
2. szabály 3. szabály 4. szabály 5. szabály 6. szabály
Ha nincs felelős projektvezető, akkor projekt sincs. Ha nincs számon kérhető, tekintélyes vezető a projekt élén, akkor a projekt előrehaladása, a termelékenység és az eredményesség, valamint a felhasználók elégedettsége nem lesz fontos projekt tényező. Ha a projekt költségeit egy harmadik fél fedezi, akkor a költségek érdektelenek lesznek Ha projekt „nagy” vagy „bonyolult”, akkor nem lesz kézben tartható, és az első neki futásra nem is fog sikerülni. Ha a leendő felhasználóknak nem kell a rendszer, akkor ne fejlesszék ki Ha az eredeti ütemterv nagyon hosszú időre vonatkozik, akkor (lényegesen) hosszabb lesz a megvalósítás során Ha a projekt célkitűzéseit nem fogalmazzák meg pontosan, határozottan és szabatosan, akkor a projekt nem fog sikerülni
A tapasztalatok és statisztikai adatgyűjtések szerint: az evolúciós, alacsony komplexitású rendszerek azok, amelyek megvalósítása elérhető.
4. Projekttámogatásban: Felelősségek és hatáskörök Projektirányító Alapfeladat és felelősség: Gondoskodik arról, hogy a projekt mint összefüggő egész az előírt termékeket állítsa elő, az előre meghatározott minőségben, valamint a költség és idő korlátokon belül maradva. A legfontosabb tevékenységek: • Megtervezi a projektet és elfogadtatja a projekttervét a projektvezetőséggel. • A kapcsolódó projektekkel tartja a kapcsolatot azért, hogy elkerüljék az egyes munkák ismételt elvégzését ill. egyes elvégzendő feladatok nehogy kimaradjanak. • Elkészíti a következő szakasz tervét és előterjeszti a projektvezetőségnek jóváhagyás végett. • Az egyes szakaszirányítók végrehajtandó feladatait és hatáskörét meghatározza. • Nyomon követi a projekt előrehaladását összességében, az erőforrások felhasználását és kezdeményezi az egyes helyreigazítási lépések végrehajtását. • Informálja a projektvezetőséget a tervtől való eltérésekről történjenek azok, akár projekt akár szakasz szinten, valamint a korrigálásukra tett helyreigazító lépésekről. • Amikor a helyreigazító tevékenységek a szakasz tűréshatárát túl lépik, a projektvezetőség számára a javasolt korrekciós tevékenységekről előterjesztést kell készíteni és az ennek megfelelő “Helyreigazítási tervet” be kell nyújtani. • A projektvezetőség számára rendszeresen tájékoztató jelentéseket kell benyújtania, amelyet a szakaszirányítók munkabeszámolóiból szerkeszt össze. • Az összes ellenőrzés jellegű találkozó, értekezlet eredményét nyomon követi, a projektbiztosító csoport tagjaival rendszeres kapcsolatot tart a projekt egységességének és haladásának kézbentartása végett. • Előkészíti a projektértékelő értekezletet. • Részt vesz az összes szakaszzáró és a projektzáró értekezleteken. • Közös álláspontot alakít ki a műszaki / technikai / informatikai és minőségi szabványokról és a folytatandó stratégiáról azokkal, akik a szervezetben ezeknek a politikáknak és előírásoknak a meghatározásáért felelősek (pl. a minőségbiztosításért felelős funkcionális szervezeti egységgel). • Létrehozza a konfiguráció kezelés struktúráját és a projekt által előállított termékek azonosítási rendszerét. Utasításokat ad: • A szakaszirányítóknak. • A projektbiztosító csoportnak. Utasításokat kap: • A szervezet hierarchikus struktúrájában az alkalmazottak irányításáért felelősöktől. • A projektvezetőségtől a projektet érintő ügyekben. Előírt tudás és gyakorlat: • Megfelelő szintű vezetési gyakorlat. • Gyakorlatban alkalmazható PRINCE ismeret. • A szervezet informatikai, információ-technológiai stratégiájának alapos ismerete. • A vonatkozó minőségi és szakmai (informatikai), műszaki szabványoknak és előírásoknak az alapos ismerete.
• •
Szakmai (informatikai) gyakorlat, tapasztalat. Megfelelő szintű projektirányítási kiképzés.
Szakaszirányító Alapfeladat és felelősség: Gondoskodik arról, hogy a az adott szakasz az előírt termékeket állítsa elő, az előre meghatározott minőségben, valamint a költség és idő korlátokon belül maradva a projektvezetőség elvárásainak megfelelően. A legfontosabb tevékenységek: • A szakasz munkacsoportjainak és a csoportvezetőinek a feladatait, felelősségét, hatáskörét meghatározza és elkészíti a munkatervüket. • Irányítja és útmutatásokkal segíti a csoportvezetőket, amikor az szükséges. • A szakasz munkacsoportjainak erőforrás-felhasználását és az előrehaladását nyomon követi, kezdeményezi - ha szükséges - a tervtől való eltérések korrigálását. • Gondoskodik arról, hogy a váratlan műszaki eseményekről korrekt jelentések készüljenek, helyesen értékeljék ezeket és megfelelő lépésekkel csökkentsék vagy küszöböljék ki a hatásukat (ha a tűréshatáron belül marad). • Részt vesz a szakaszértékelő üléseken és az előző szakasz szakaszzáró értekezletén. • Megszervezi az összes szakasz ellenőrzésre hivatott találkozót. • Együttműködik a projektbiztosító csoporttal azért, hogy a szakasz megfeleljen az adminisztratív, szakmai (informatikai) és az adat integritási követelményeknek. • Előkészíti a részletes terveket ha szükség van rájuk. • A minőségi szemlék terv szerinti megtartását biztosítja. • Naprakész állapotban tartja vagy tartatja a szakasz dokumentációját. Akkor, amikor a projektirányító szerepét egy másik személy tölti be még a következő feladatok tartoznak ide: • Segíti a projektirányítót a következő szakasz szakmai/műszaki és erőforrástervének előállításában. • Egyezteti a szakasz terveit a projektirányítóval. • Értesíti a projektirányítót a tervtől való eltérésekről, javaslatot tesz a korrekciós tevékenységekre és segít előkészíteni a Helyreigazítási Tervet. • Rendszeres tájékoztató jelentéseket készít a projektirányítónak. Utasításokat ad: • A munkacsoport vezetőknek. • A munkacsoportnak (a csoportvezetőn keresztül, ahol van kinevezett csoportvezető). Utasításokat kap: • A szervezet hierarchikus struktúrájában az alkalmazottak irányításáért felelősöktől. • A projektvezetőségtől és a projektirányítótól a projektet érintő ügyekben. Előírt tudás és gyakorlat: • Megfelelő szintű szakmai (informatikai) tapasztalat. • Gyakorlatban alkalmazható PRINCE ismeret. • A vonatkozó minőségi és szakmai (informatikai), műszaki szabványoknak és előírásoknak az alapos ismerete, a szervezet helyi előírásait is beleértve. • A szakaszban végrehajtandó tevékenységekhez és az előállítandó termékekhez kapcsolódó szakmai ismeretek háttere.
Projektbiztosító csoport A projektbiztosító csoport három szerepkörből áll. Ezek a szerepek a • Adminisztratív koordinátor. • Szakmai koordinátor (felelős). • Felhasználói koordinátor. • Külső szakértő tanácsadó. Az egyes tagok hatás- és feladatkörét, felelősségét az alábbiakban írjuk le. Az adminisztratív koordinátor Alapfeladat és felelősség: Az adminisztratív, szervezeti érdekekkel kapcsolatos dolgok tervezése, nyomon követése és a beszámoló jelentések készítése, ez a szerep az adminisztratív irányítás és ellenőrzés megvalósításának eszköze. A legfontosabb tevékenységek • Segíti a projektirányítót a projekt erőforrástervének elkészítésében és biztosítja az összhangját projekt szakmai tervével. • Minden szakasz végén segíti a projektirányítót a következő szakasz erőforrástervének elkészítésében és gondoskodik arról, hogy a projekt erőforrástervével és a következő szakasz szakmai tervével összhangba legyen. • Minden szakasz részletes tervét a szakaszirányítóval közösen készíti el. • A technikai koordinátorral közösen egyeztetik a részletes terveket és a műszaki (szakmai) terveket. • A projekt tagjai számára erőforrás tervezési segítséget és útmutatást nyújt. • A PRINCE minőségi szemlékkel kapcsolatos tevékenységeket koordinálja és szervezi. • Szervezi és koordinálja a PRINCE helyreigazítási és korrekciós lépéseket. • A projekt egésze és a konfiguráció kezelés közti kapcsolat tartást megteremti és szervezi. • Megszervezi a konfiguráció auditálási eljárásokat. • Gyűjti az aktuális erőforrás felhasználási adatokat és az egyes tevékenységi területekre terheli. • Nyomon követi a tényleges erőforrás felhasználást a tervezettel szemben és az időarányos teljesítést. Bármilyen eltérést jelent a szakaszirányítónak. • Részt vesz a munkabeszámoló értekezleteken. • Segíti a szakaszirányítót a munkabeszámolók elkészítésében. • Segíti a projektirányítót a projektvezetőség számára szóló tájékoztató jelentések elkészítésében. • Figyelemmel kíséri a projekt költségtervében előírtakhoz képest a projekt előrehaladását és a költségek alakulását. • Segíti a szakaszirányítót a szakasz értékelő ülésekről készítendő jelentések adminisztratív (pénzügyi) oldalának kidolgozásában. • A szakaszközi és szakaszzáró értekezleteken részt vesz és jegyzőkönyvezi azokat. • Segíti a projektirányítót a projektvezetőség számára szóló helyreigazítási tervek elkészítésében. • Segíti a szakaszirányítót a szakasz (projekt) dokumentációjának létrehozásában és napra készen tartásában. • A minőségirányítással kapcsolatos dokumentációs rendszert kialakítja és napra készen tartja. • Közreműködik a projekt kiértékelésben.
Utasításokat kap: ♣ A projektvezetőségtől és a projektirányítótól a projektet érintő ügyekben. ♣ Ezenkívül még a munkáját irányítják a fontosabb kérdésekben a következők: az projektvezetőség ügyvezetője (elnök), a szakaszirányító, a szakmai koordinátor, és a felhasználói koordinátor. Előírt tudás és gyakorlat: • Pénzügyi, gazdasági és adminisztrációs ügyintézési gyakorlat. • A költségek és hasznok közötti összefüggések ismerete, elemzési gyakorlat. • Gyakorlatban alkalmazható ismerete az erőforrás- és ütemtervezési (szabványos) eljárásoknak és módszereknek. • Gyakorlatban alkalmazható PRINCE ismeret. • Az informatika, és az információ-technológia alapfogalmainak ismerete. • A helyi, szervezeti vonatkozó szabványoknak, előírásoknak az ismerete. A szakmai koordinátor Alapfeladat és felelősség: A projekt szakmai, informatikai, műszaki, technikai, oldalaival összefüggő dolgok tervezése, nyomon követése és a beszámoló jelentések készítése; ezen keresztül a projektre vonatkozó informatikai, műszaki, és üzemeltetési előírások, szabványok és szabályozás betartatása a projektre gyakorolt jótékony hatás érdekében. A legfontosabb tevékenységek • Segíti a projektirányítót a projekt szakmai tervének elkészítésében és biztosítja az összhangját projekt erőforrástervével. • Minden szakasz végén segíti a projektirányítót a következő szakasz szakmai tervének elkészítésében és gondoskodik arról, hogy a projekt szakmai tervével és a következő szakasz erőforrástervével összhangba legyen. • Minden szakasz részletes tervét a szakaszirányítóval együtt készítik el. • Az adminisztratív koordinátorral közösen egyeztetik a részletes terveket és az erőforrásterveket. • Segíti a projektirányítót és szakaszirányítót a projektnek megfelelő informatikai, műszaki stratégia és módszerek kiválasztásában. • A szakmai (informatikai) termékek minőségellenőrzési kritérium rendszerének kialakításában és az egyes termékekre vonatkozó ellenőrzési listák összeállításban közreműködik, részt vesz a szakmai/technikai termékek minőségi szemléin. • A konfiguráció kezelés módszerének alkalmazását a projektben tanácsokkal segíti. • A fejlesztés alatti rendszer üzemeltetési és karbantartási kérdéseinek megoldását a tanácsaival támogatja. • Szakmai, technikai szempontból átvizsgálja a rendszerrel szemben támasztott biztonsági követelményeket, vajon megfelelnek-e a bizalmas adatok védelme, az adatok integritásának (teljességének és összefüggőségének) megőrzése és a rendelkezésre állás, elérhetőség szempontjából. • A rendszer helyreállítási eljárásokat átvizsgálja technikai szempontból. • Az informatikai, műszaki, technikai szabványok és műszaki minőségbiztosítási módszerek helyes alkalmazásának biztosítása. • Nyomon követi a projekt technikai előrehaladását, a szakaszirányítót értesíti a jelentősebb eltérésekről. • Részt vesz a munkabeszámoló értekezleteken és segít a szakaszirányítónak küldendő beszámolók elkészítésében.
•
Részt vesz a minőségi szemléken (ott ahol szükséges) és gondoskodik a minőségellenőrzési eljárások megfelelő és eredményes alkalmazásáról. • Segíti a projektirányítót a projektvezetőség számára szóló tájékoztató jelentések elkészítésében. • Segíti a szakaszirányítót a szakaszközi és a szakaszzáró értékelő ülésekről készítendő jelentések szakmai (informatikai) és technikai oldalának kidolgozásában. • A szakaszközi és szakaszzáró értekezleteken részt vesz. • A váratlan műszaki események helyes értékeléséről gondoskodik, ide értve a kapcsolódó projektek által jelzetteket is. • Segíti a projektirányítót a helyreigazítási tervek korrekciós lépéseinek meghatározásában. • A változtatási kérelmek és a specifikációtól való eltérések műszaki következményeit segít elemezni. • A projekt műszaki dokumentációs rendjének létrehozásáról és napra készen tartásáról gondoskodik. • A projekt tagjai számára segítséget és útmutatást nyújt a szakmai (informatikai) és műszaki problémák, szabványok, előírások és szabályozások területén. • Biztosítja, hogy a változtatási kérelmek nem csorbítják a rendszer teljességét, egységességét, összefüggőségét. • Közreműködik a projekt kiértékelésben. Utasításokat kap: • A projektvezetőségtől és a projektirányítótól a projektet érintő ügyekben. • Ezenkívül azok, akik még a munkáját irányítják a fontosabb kérdésekben a következők: a szakaszirányító, az adminisztratív koordinátor, a projektvezetőség szakmai felelőse, és a felhasználói koordinátor. Előírt tudás és gyakorlat: • Több éves vezetői tapasztalat a rendszerelemezésben és tervezésben (rendszerszervezésben), az SSADM vagy a szervezetnél használt rendszerelemzési és tervezési módszertan ismerete előnyös. • Az informatikai, és az információ-technológiai rendszereknek és a vezérlő, irányító szoftvereknek a gyakorlatban alkalmazható ismerete. • Gyakorlatban alkalmazható PRINCE ismeret. • Az alkalmazható informatikai, műszaki, technikai előírások, szabályok, módszerek, szabványok ismerete (pl. SSADM és a kormányzati biztonság technikai ajánlások). • Az üzemeltetési szabályok, előírások és szabványok ismerete. • A konfiguráció kezelés szabványainak és szabályainak ismerete. A felhasználói koordinátor Alapfeladat és felelősség: A projekt felhasználói oldalaival összefüggő dolgok nyomon követése és a beszámoló jelentések készítése; valamint a felhasználói érdekek naprakész képviselete. A legfontosabb tevékenységek • Nyomon követi a felhasználói igényekkel kapcsolatos bármilyen problémák megjelenését a rendszer fejlesztése során, ezekről beszámol a felhasználói részlegek vezetésének.
•
Gondoskodik arról, hogy a felhasználók megértsék a felhasználói szintű specifikációt és ellenőrzi, hogy a velük való egyeztetés megtörtént-e, azzal egyetértenek-e. • Előkészíti a projekt adat könyvtárait és az ellenőrzése alatt tartja, a felhasználók részéről a rendszer átvételéhez és elfogadásához szükséges tesztek és azokhoz szükséges adatok előkészítését ellenőrzi. • Ellenőrzi és gondoskodik róla, hogy a felhasználók számára szükséges összes dokumentációt a projekt tervben rögzítették (mint pl. a felhasználói kézikönyvek, oktatási anyagok, a munkahelyek és munkaállomások ergonómiai terve, stb). • A követelmény specifikációban a munkaszervezési illetve átszervezési igényekből származó követelmények megjelenéséről gondoskodik. • A felhasználói átadás/átvételi (elfogadási) kritérium rendszert létrehozza vagy létrehozatja. • Közreműködik a minőségellenőrzési kritériumok összeállításában, átvizsgálja az egyes termékek minőség-ellenőrzési listáját és a felhasználók által véleményezendő termékek minőségi szemléi meghívottjainak listáját is leellenőrzi. • A felhasználói átadás/átvételi eljáráshoz szükséges teszt adatok előállítását megszervezi. • A felhasználói szintű tesztelés eredményeinek helyesség ellenőrzéséről, az adatok korrektsége szempontjából, gondoskodik. • Felhasználói szempontból átvizsgálja a rendszerrel szemben támasztott biztonsági követelményeket, vajon megfelelnek-e a bizalmas adatok védelme, az adatok integritásának (teljességének és összefüggőségének) megőrzése és a rendelkezésre állás, elérhetőség szempontjából. • A rendszer helyreállítási eljárásokat átvizsgálja a felhasználók szemszögéből. • Gondoskodik arról, hogy a projekt betartsa a vonatkozó adatkezelési szabványokat, szabályokat és eljárásrendet. • Leellenőrzi, hogy a felhasználók összes adatokkal kapcsolatos igényét a rendszerelemzés során figyelembe vették-e. • Részt vesz a minőségi szemléken (ott ahol szükséges) és gondoskodik a projekt adatszerkezeti oldalának egységességéről, összefüggőségéről és teljességéről. • Részt vesz a munkabeszámoló értekezleteken és segít a szakaszirányítónak küldendő beszámolók elkészítésében. • Segíti a projektirányítót a projektvezetőség számára szóló tájékoztató jelentések elkészítésében. • Segíti a szakaszirányítót a szakaszközi és a szakaszzáró értékelő ülésekről készítendő jelentések elkészítésében. • A szakaszközi és szakaszzáró értekezleteken részt vesz. • A váratlan műszaki események felbukkanását nyomon követi és segíti a felhasználói területekre gyakorolt hatást kiértékelni. • Gondoskodik arról, hogy a felhasználók a változtatási kérelmek következményeit és hatását világosan megértették és elfogadták. • Segíti a projektirányítót a helyreigazítási tervek elkészítésében. • Közreműködik a projekt kiértékelésben. Utasításokat kap: • A projektvezetőségtől és a projektirányítótól a projektet érintő ügyekben. • Ezenkívül azok, akik még a munkáját irányítják a fontosabb kérdésekben a következők: a szakaszirányító, az adminisztratív, a szakmai koordinátor, a
projektvezetőség felhasználói képviselője, és a felhasználói kapcsolattartásért felelős tisztviselő. Előírt tudás és gyakorlat: • Az adatkezeléssel összefüggő szabványok, szabályok ismerete. • Gyakorlatban alkalmazható PRINCE ismeret. • Az adatbázisok és az adatbázis-kezelő rendszerek alapfogalmainak ismerete. • A szervezetnél használt adatbázis-kezelő rendszerek ismerete. • A felhasználók napi munkájának gyakorlati ismerete és annak a tudása, hogy ezek a feladatok, hogyan fognak módosulni a projekt hatásaként. • A kifejlesztendő rendszer használhatóságában szerepet játszó emberi tényezők jelentőségének megértése. • Személyes adottságai tegyék lehetővé, a felhasználók és a szakmai (informatika) stáb közti zökkenőmentes kommunikáció és információ csere megvalósítását.
Külső szakértő / tanácsadó A projektbiztosító szervezet részeként a projektirányító illetve az egész projektszervezet támogatására külső szakértők vonhatók be (szervezeti / üzleti rendszerelemezők, szervezők, informatikai szakértők, módszertani, fejlesztési, biztonsági, szakemberek, informatikai ellenőrök, stb.). Az állam és közigazgatási szervezetekben ezek a szakértők nem vehetik a döntés felelősségét a felelős, a feladatra kijelölt államigazgatási szakemberektől, azonban a Megrendelő szervezeti, szakmai érdekeinek és szempontjainak lojális támogatásával segítik az informatikai és telekommunikációs projektek megvalósítását, természetesen a saját informatikai, műszaki szakmai meggyőződésük képviselete mellett. A tanácsadást biztosító konzultánsokkal szemben a következő elvárások vannak: •
Ismerniük kell a magyar államigazgatás informatikai gyakorlatát, feltétel rendszerét;
•
Ismerjék a magyar államigazgatásban érvényes, elfogadott informatikai irányelveket;
•
Rendelkezzenek a magyar államigazgatásban végrehajtott informatikai és információ rendszerekkel kapcsolatos fejlesztési és projektirányítási tapasztalatokkal;
•
Ismerjék a magyar államigazgatásban az informatikára vonatkozó ajánlásokat (ITB ajánlások), legyenek gyakorlati tapasztalataik ezek alkalmazásában;
•
Rendelkezzenek megalapozott ismeretekkel a szervezet működéséről, beleértve az informatikai támogatás helyzetét;
•
Szükség szerint: Legyen gyakorlatuk és tapasztalataik nemzetközi együttműködésben végrehajtott projektekről, különös tekintettel a PHARE szabályoknak megfelelő tender kiírásokkal kapcsolatban, továbbá a nyertes ajánlattevőkkel együtt a sikeres projekt együttműködés megvalósításában.
Ennek megfelelően a szakmai tanácsadók tevékenysége az egyes — a projekt folyamán további részfeladatokra bomló — feladatok segítése a projektszervezet és a minisztérium oldalán úgy, hogy az MEGRENDELŐ szakmai érdekei és szempontja érvényesüljenek. A munkát kölcsönös egyetértés alapján megállapított ütemezésben kell ellátni, a projektszervezet az adott időszakra ütemezett feladatainak segítése érdekében. A tanácsadásra ki kell jelölni a vezető konzulenst, aki a tanácsadási folyamatot összefogja. Ajánlatos ISACA / CISA vizsgával, rendszerszervezési és tervezési oklevéllel (pl. pl. SSADM, stb.) rendelkeznie, projektirányítási módszertanok ismeretével és gyakorlati tapasztalataival (PRINCE I, PRINCE II., stb.). A feladat elvégzéséhez további konzulenseket is ki lehet jelölni a felmerülő szakkérdések (tender kiírás támogatása, szolgáltatási szint meghatározás, követelményspecifikáció készítése, stb.) támogatására. Estleges tender kiírásba, műszaki mellékletek „megvalósíthatósági tanulmány szintű” elkészítésébe csak a Kbt. összeférhetetlenséggel kapcsolatos szabályozásának
14
megfelelő szakértők vonhatók be. Az aktuális tanácsadói munkában résztvevők és a rajtuk keresztül érintett szervezetek a majdani közbeszerzési pályázaton nem indulhatnak.
Adatadminisztrátor AZ adatadminisztrátor fő feladata, hogy a kifejlesztett rendszer összhangban legyen a szervezeti adatadminisztrációs szabályokkal, előírásokkal, különös tekintettel az elnevezési konvenciókra, az adattárolási módokra, az adatok közös és megosztott használatára stb. A további részletek az „Informatikai Tárcaközi Bizottság ajánlásaiban, az ’Adatmenedzsment a kormányzatban’ 11. sz. ajánlásában” a http://www.itb.hu/ajanlasok/a11 (2001. május 3.) címen találhatóak.
Informatikai ellenőr (auditor) Főb feladatai az ellenőrnek: • A projektben készülő rendszer ellenőrzési és vezérlési, biztonsági mechanizmusok, eljárásainak értékelése. • A végrehajtott, a rendszert lényegesen érintő tranzakciók nyom követésére kialakított mechanizmus értékelése. • A fejlesztő csoport mellett olyan tanácsadóként működik mint aki a rendszer ellenőrzési, irányítási mechanizmusaiban tud szakmai segítséget nyújtani. • Megtervezi a jövendő informatikai ellenőrzések követelményeit. Az ellenőr eljárási szabályait a következő források tartalmazzák: • Az informatikai ellenőrzés eljárásrendje, szabályai, etikai előírásai, a következő címen találhatók: http://www.isaca.org/stand1.htm (2001. május 3.) • A felső vezetés szempontjából az informatikai rendszerek, és a folyó projektek kézben tartásának és irányításának szempontrendszere ezen a címen találhatók: http://www.isaca.org/cobit.htm (2001. május 3.)
Ellenőrzés, minőségbiztosítás A minőségbiztosítással, ellenőrzéssel foglalkozók legfőbb feladatai: • A fejlesztési projekt elindítása előtt áttekintik a szabályozásokat, eljárásrendet, alkalmazni tervezett fejlesztési módszertant. • Felülvizsgálják és a tervezett költségvetés és az egyéb tervek ésszerűségét, kivitelezhetőségét. • Nyomon követik, monitorozzák a fejlesztési szabványok és eljárások betartását. • Ellenőrzik az egyéb, ide vonatkozó szervezeti szabályozásoknak, politikáknak való megfelelőséget. • A projekt által elkészített dokumentációk és egyéb termékek eredményes és sikeres előállítását is ellenőrzik. • Felülvizsgálják és lehetőség szerint be is vizsgálják a rendszer tesztelési és konverziós eljárásokat.
Biztonsági felelős • •
Ellenőrzi, hogy a kifejlesztett rendszer megfelel-e a szervezet biztonsági előírásainak. Vegyen részt annyira a fejlesztési munkálatokban, hogy át tudja venni a biztonsági követelmények kivitelezését, üzembe helyezését és a folyamatos karbantartást az üzemi rendszernél.
15
•
A fejlesztés alatt álló programok, forrás kódok védelméről gondoskodni kell
16
5. Előírások, szabványok A projektszervezetnek figyelemmel kell lennie sok informatikai, szakmai, műszaki előírás, szabvány betartására. Minőségi szabványok: • ISO-9001 (ISO - International Standardization Organization) • BS-5750 (BS - British Standard) • Vonatkozó fontosabb szabványok: ISO 9000-3, ISO 9000:2000 • ISO 9126, szoftver rendszerek minőségi kritériumai, szempontrendszere Dokumentációs szabványok • ISO 6592 • SSADM, Brit szabvány, BS7738-94 • CCTA, Central Communication and Telecommunication Agency, SSADM Version 4+, Reference Manual, NCC Blackwell Mancshester, Oxford, 2001
17
6. Projektek informatikai ellenőrzése A rendszerfejlesztési projektek irányítási magában foglalja a projektirányítást, a felhasználók bevonását, a minőség ellenőrzést és az informatikai ellenőrzést, auditot. •
A minőség ellenőrzés: feladata az, hogy biztosítsa, hogy minden leszállítandó termék a megkívánt minőségű és minden munkát pontosan a vonatkozó előírások és szabályok szerint hajtották végre. • Informatikai ellenőrzés: általában egy olyan eljárás, amikor a szemlézők, akik nem tagjai a projekt fejlesztő csoportjának megvizsgálják és kiértékelik a projekt terveket, az előállított termékeket, a projekt vezetés mikéntjét, vizsgálják azt, hogy mennyire vannak összhangban az előre meghatározott szabályokkal, előírásokkal és szervezeti követelményekkel. A minőség ellenőrzést a belső ellenőrzési csoport / osztály, külső informatikai revizorok, egy független minőségbiztosító csoport vagy tetszőleges kombinációjuk hajthatja végre. A szoftver minőségbiztosítást a következő témakörök érintik: • A rendszerfejlesztési és programozási szabványok megfogalmazása, előírása (pl. vonatkozó módszertanok, SSADM, UML); • A projekt által elkészített rendszer dokumentációt bevizsgálják, miszerint megfelelnek-e az előírt fejlesztési szabványoknak és eljárásoknak ; továbbá a kifejlesztett új rendszer tartalmazza-e azokat az eljárásokat, amelyek lehetővé teszik a rendszer hatékony és eredményes ellenőrizhetőségét és kézben tarthatóságát. • Felülvizsgálják és lehetőség szerint be is vizsgálják a rendszer, a program tesztelési és konverziós eljárásokat. Továbbá a párhuzamos rendszer üzemeltetést és a kísérleti rendszerek futtatását (pilot) ellenőrzik, hogy vajon megfelelnek-e az előírt szervezeti szabályoknak, szabványoknak. • Felülvizsgálják és lehetőség szerint be is vizsgálják a rendszer adat konverziós eljárásait, vajon helyesek-e és megfelelnek-e a vonatkozó előírásoknak. • Nyomon követik, monitorozzák a fejlesztési, programozási szabványok és eljárások betartását. • Biztosítják, hogy a projektben készülő rendszer ellenőrzési és vezérlési, biztonsági mechanizmusai, eljárásait a fejlesztés során specifikálták-e és a beépítésük megtörtént-e. • A végrehajtott, a rendszert lényegesen érintő tranzakciók nyom követésére kialakított mechanizmust megtervezték-e és beillesztették-e a rendszerbe.
18
I.
Projektirányításban való jártasság felmérése Igen
Nem
Követelménykezelés 1. A leendő rendszerre megállapított felhasználói követelményeket termék mérföldkőként használják-e fel a tervezés és a projektirányítás következő lépéseiben ? 2. Miután a követelményeket rögzítették, módosítják-e a rendszerfejlesztési projektterveket, leszállítandó termékeket, tevékenységeket? 3. Van-e írásban rögzített eljárás a rendszerrel szemben támasztott követelmények kezelésére? 4. A követelményekkel foglalkozó projektrésztvevőket kiképezték-e a követelmények kezelésére? 5. Használnak-e olyan informatikai mennyiségeket, mértékeket, amelyek a követelményekkel kapcsolatos tevékenységek előrehaladását, teljesülését mérik? 6. A követelményekkel kapcsolatos tevékenységeket alávetik-e minőségellenőrzési eljárásoknak (pl. ISO 90003, ISACA/ COBIT projekt audit, stb.)? Rendszerfejlesztési projekt tervezése 1. A projektre (nagyságára, méretére, ütemetervére, határidőkre, stb.) vonatkozó becslést a tervezési folyamat során írásban rögzítik-e azért, hogy a későbbiekben nyomon
19
Nem Nem értelmezhető tudja
követhető legyen? 2. A projekt terv dokumentálja-e a végrehajtandó tevékenységeket és a hozzá rendelt erőforrásokat? 3. Van-e a szervezetnek írásban rögzített eljárásrendje a projekttervezésre? 4. Használnak-e olyan informatikai mennyiségeket, mértékeket, amelyek a projekttervezési tevékenységek előrehaladását, teljesülését mérik? (a projekttervezési mérföldkövek teljesülése a tervekhez viszonyítva) 5. A projektirányító rendszeresen felméri-e a projekttervezés előrehaladását, ha szükséges akkor az eseményekhez igazodva? A rendszerfejlesztési projekt nyomon követése és ellenőrzése. 1. A projekt aktuális helyzetét, eredményeit rendszeresen össze vetik-e a projekttervben szereplő becslésekkel? ( ütemterv, határidők, nagyság, méret, költség, stb.) 2. Ha a terv és teljesítést között jelentős eltérések lépnek fel, meg teszik-e a szükséges korrigáló lépéseket? 3. Van-e a szervezetnek írásban rögzített eljárásrendje a rendszerfejlesztési projekt nyomon követésére és ellenőrzésére? 4. Van-e valaki a projektben megbízva azzal, hogy a munka eredményét és a tevékenységeket nyomon kövesse? (ráfordítások, határidők, költségek))
20
5.
Használnak-e olyan informatikai mennyiségeket, mértékeket, amelyek a projekt nyomkövetési és ellenőrzési tevékenységek előrehaladását, teljesülését mérik? (projekt nyomkövetési és ellenőrzési tevékenységekre fordított munkát) 6. A projekt nyomkövetési és ellenőrzési tevékenységekre fordított munkát rendszeresen megvizsgálja-e a felső vezetés (projektek teljesítménye, eredménye, nyitott kérdések, kockázatok és cselekvési tervek.) Minőségbiztosítás 1. Tervezik-e a minőségbiztosítási lépéseket? 2. A minőségbiztosítási lépések objektív mércét adnak-e arra, hogy fejlesztés termékei és tevékenységei betartják-e a vonatkozó szabványokat és szabályozásokat, eljárásokat és követelményeket? 3. A minőségbiztosítási eljárások, vizsgálatok auditok eredménye eljut-e az érintettekhez (a munkát végzők, illetve az eredményekért felelősökhöz)? 4. Van-e a szervezetnek írásban rögzített eljárásrendje a rendszerfejlesztési minőségbiztosítására? 5. Használnak-e olyan informatikai mennyiségeket, mértékeket,
21
amelyek a minőségbiztosítási tevékenységek előrehaladását, teljesülését mérik? (befejezett vizsgálatok, ráfordítások és költségek összevetve a projektervvel)
22
II.
Minták: Dokumentumokra ill. tartalomjegyzékükre
II.1
Projektalapító dokumentum tartalomjegyzéke
A.
FEJEZET: BEVEZETÉS A PROJEKTBE
A.1. A.1.1. A.1.2. A.1.3. A.1.4. A.1.5. A.1.6. A.1.7. A.2.
B.
FEJEZET: A PROJEKT MEGHATÁROZÁSA
B.1. B.2. B.3. B.3.1. B.3.2. B.3.3. B.3.4.
C.
A projekt felügyeletének megszervezése Az ellenőrzési pontok, áttekintések Értékelések Munkamegbeszélések és tájékoztatók Minőségbiztosítás Változás menedzsment Irányítási kapcsolat más projektekkel
FEJEZET: PROJEKTTERV
E.1. E.2. E.3. E.4. E.4.1. E.4.2. E.4.3. E.5.
F.
Projektvezetőség Projektirányítók Vezető felhasználói képviselő Vezető informatikai képviselő Felhasználói összekötő A projekt biztosító csoport Adminisztratív koordinátor Felhasználói koordinátor Informatikai koordinátor
FEJEZET: FELÜGYELET ÉS IRÁNYÍTÁS
D.1. D.2. D.2.1. D.2.2. D.3. D.4. D.5.
E.
Célkitűzések Hivatkozási alap (feladatok) Projekt behatárolása Szakaszolás A projekt végtermékek (illetve fontosabb szakaszzáró termékek) Szabványok és módszerek Oktatás
FEJEZET: A PROJEKT SZERVEZET
C.1. C.2. C.3. C.4. C.5. C.6. C.6.1. C.6.2. C.6.3.
D.
Háttér Jogi háttér Fogalmak, rövidítések Az alkalmazási terület főbb ismérvei Az alkalmazási terület részei A szervezeti folyamat fő lépései: Az szervezeti folyamat részterületei: További információk Kapcsolat egyéb rendszerekkel és projektekkel
Projekt szakmai terv Projekt erőforrásterv Tűrés Korlátozó tényezők Elhelyezés Szervezet Személyzet Egyéb feltételek
FEJEZET: AZ ELSŐ SZAKASZ TERVE
G. MELLÉKLETEK G.1. G.1.1. G.1.2. G.1.3.
A melléklet: Felelősségi- és hatáskörök leírása Projektvezetőség Projektirányítók Felhasználói képviselő
23
G.1.4. G.1.5. G.1.6. G.1.7. G.2. G.3. G.4. G.5.
II.2
Informatikai képviselő Adminisztratív koordinátor Felhasználói koordinátor Informatikai koordinátor D melléklet: A konkrét projekt tervek F melléklet: Részletes terv az első szakaszra G melléklet: Kapcsolódások H. melléklet: Biztonsági szempontok
Projekt előrehaladási jelentés tartalomjegyzéke
A projektvezető feladat, hogy rendszeres időközönként beszámoljon az illetékes vezetőknek, testületeknek a projekt előrehaladásáról. A jelentések gyakoriságát a nagyvonalú projekttervben, a szerződésben kell meghatározni, tekintettel a projekt kockázatára. Állapot jelentés előlapja: Beszámolási időszak / hónap. Projektazonosító Projekt megnevezése Megrendelő Szerződés típus Teljesítési időszak Készítés dátuma (beszámolási hónap vége + 10 nap) Készítette: Aláírás, dátum Projektvezető Aláírás, dátum Szoftver minőségellenőr Aláírás, dátum
Tartalomjegyzék 1 Projekt állapota 1.1 Projekt költségek alakulása 1.1.1 Terv kontra aktuális helyzet költség grafikon 1.2 Projektre fordított munkaerő felhasználás 1.2.1 Terv kontra aktuális helyzet munkaerő felhasználásban 1.3 Projekt ütemterv aktuális helyzete 1.3.1 Gantt diagram, hálóterv 1.4 Projekt problémák, ügyek, kockázatok, feladatterv 1.4.1 Konfliktusok, problémák nem feloldhatók a projekten belül 1.4.2 Projekt kötelezettségei, ígérvények illetve ezek változásai 1.4.3 Projekt kockázatok és minimalizálási lehetőségek 1.5 Szoftver mértékek, mennyiségek (metrikák) 1.5.1 Terv kontra aktuális helyzet 1.5.2 Korrekciós lépések terve 1.6 Projekt minőségbiztosítási feladatok és eredményeik
24
1.6.1 Nem megfelelő tételek 1.6.2 Minőségbiztosítási költségek 1.6.3 Minőségbiztosítási feladatok ütemezése 1.6.3.1 Gantt diagram, hálóterv 1.6.4 Korrekciós lépések terve 1.7 Szoftver konfiguráció kezelés helyzete 1.7.1 Konfigurációkezelési, változáskezelési mértékek, szoftver mennyiségek 1.7.2 Konfigurációkezelés költségei 1.7.3 Korrekciós lépések terve 1.8 Megrendelői megelégedettség / Szervezeti lehetőségek
25
II.3
A projekt leszállítandó főbb termékei szakaszonként Módszertani alapon (pl. SSADM, UML)
Termékek
Projekt tervezés
Automatizált és manuális tesztelési eljárások Projekt beruházási alapokmánya L (szervezeti szükségletek alátámasztása) Szervezeti folyamatok prototípusa Változáskezelés Programozás, (program) kódolás Nagy vonalú fogalmi / Koncepcionális L terv készítése Konverzió, áttérés tervezése Átkonvertált adatok Adatkonvertálási eljárások Rendszertervez Az alkalmazás architektúrális terve (szoftver / hardver) Funkciók, adatcsere, alkalmazás vezérlési struktúrája Logikai adatbázis terve Felhasználói felület terve Munkafolyamat diagram Üzemeltetési / használati útmutató Áttérés / konverzió utáni értékelő jelentés Projekt terv L Követelmény specifikáció Adatmodell Esemény modell Folyamat modell Minőségi követelmények Telepítési terv Teszt adatbázis Teszt modell
Elemzés
Tervezés
F, M
F
L
F
Rendszerkészítés / építés
F
Felhasználói eljárások képzés F
Teszt tervezés és Tesztelés és előkészítés L
F
F
F
Telepítés tervezése
Telepítés
F
F L
L
F
F F
L L
F
F
L L L L
F,M L L L L L
F,M F F F F F
L L L F F
F F F
F F F
F,M
F F F L F,M
F F L F,M F F F F F
F,M
L L
26
F F
F
F,M
F,M
L
F
Módszertani alapon (pl. SSADM, UML) Termékek Tesztelési terv Tesztelési eredmények Képzési tematika Képzési anyagok Program egység tesztek eredményei Felhasználói dokumentáció Vázlatos felhasználói dokumentáció
Projekt tervezés
Elemzés
Tervezés
Rendszerkészítés / építés
Felhasználói eljárások képzés
Teszt tervezés és Tesztelés és előkészítés L
Telepítés tervezése
Telepítés
F L,F
L, F L, F L, F L Jelmagyarázat
27
L F L F M
F Létrehoz Felülvizsgál Módosít
F
II.4
Tesztelési eljárás az üzemi rendszer átvételére
A tesztelési eljárás lényege, hogy bizonyítsa, a program, a szoftver részrendszer vagy az alkalmazási rendszer a tervekkel összhangban viselkedik. A tesztelésnek azt is meg kell állapítania, hogy a tesztelendő egység nem mutat hibás müködést és nem okoz károkat, hibákat a rendszer további alkotórészeiben, amikkel együtt vagy párhuzamosan müködik. I. Alapteszt A. Az általános elfogadott minimális tesztelés értendő ez alatt. Az, ami a a szóban forgó rendszer számítástechnikai működőképességet bizonyítja. Ezek végrehajtása nélkül a rendszer semmilyen formában sem vehető át. (A rendszert készítők feladata) II. Rendszerelem teszt A. A programozó feladata, hogy biztosítsa, hogy az adott program teljes mértékben és helyesen a saját tezst adatai alapján működik. Ez biztosítja azt, hogy a program átment a kötelező hibakeresési eljárásokon, és műszakilag összhangban a rendszerszervezők, rendszerelemzők által előállított követelményspecifikációval. (A rendszert készítők feladata) III. Rendszer teszt A. A rendszert készítő, tervező rendszerszervezők és rendszerelemzők feladata az, hogy biztosítsák, hogy mindegyik program összes része helyesen és pontosan müködik együtt a tervezett adatszerkezettel, a bemenetet és kimenetet kezelő hardver és szoftver eszközökkel, és egyéb programokkal. A rendszer bizotonsága miatt fontos, hogy a fejlesztők az „éles” adatokhoz ne férhessenek hozzá, csak a saját maguk által előállított teszt adatokhoz, illetve olyan adatokhoz, amelyeknek a felhasználására engedélyt kaptak. Ez az adatfelhasználást a megfelelő szintű vezetének kell engedélyenie. (A rendszert készítők feladata) IV. Felhasználói elfogadás tesztje A. A rendszer átvétele és bevezetése előtt, a felhasználói részlegeknek ellenőriznie kell, hogy az általuk támasztott követelményeknek megfelel-e a rendszer, a programok és az alkalmazási rendszer képes-e a valóságban előforduló helyzeteket kezelni (rendszeres illetve rendkivüli eseménysorozatok, (adat)biztonsági kérdések, belső ellenőrzés lehetőségei, munkaterhelés nagysága, stb.). Fel van- készítve az összes előforduló és bekövetkezhető helyzetre? Ehhez a teszteléshez általában a valós adatokra, állományokra van szükség, illetve olyan teszt adata halamzokra, amelyekre nem lehet példát találni az éppen aktuális és „éles” adatok között. B. Lényeges az, hogy ezt a tesztelést kézben tartsák. A várt és aktuális értékeket dokumentálni kell és az eltéréseket fel kell jegyezni. A rendszerfejelesztőknek a programok javítása miatt beálló változásokat kell kézben tartani. C. A sikeres felhasználói, (szakmai informatikai) teszt után a felhasználói vezetésnek, a projektvezetőségnek, a minőségbiztosító csoportnak, a biztonsági adminisztrátornak / felelősnek pozítiv elfogadási nyilatkozatot kell kibocsátania.
D.
Információrendszer esetében egy rendszer bevizsgálást (auditot) érdemes végrehajtani. Pénzügyi információrendszer esetében pénzügyi audit (könyvvizsgálás elvégzése is szükséges) V. További tesztelések A. Átvételi forgatókönyv 1. egy részleg a szoftver rendszer átvehetőségére egy kezdeti tesztet hajt végre, amely nem teljes és nem is kimerítő. B. Párhuzamos teszt 1. A régi és új rendszer egy ideig párhuzamosan üzemeltetik, ugyanazon az adathalmazon. C. Regresszió teszt 1. Kliens-szerver (ügyfél-kiszolgáló) architketúrájú rendszerekben iszonyatos fontos teszt fajata. Ekkor leellenőrzik azt, hogy ha nem minden kliens munkaállomáson frissítették a program verziókat egyidejűleg, ekkor bizonyítani kell, hogy a különböző kliens program verziók egymás mellett létezése nem okoz károkat az adatbázisban, a különböző verzió szintek “békésen egymás mellett tudnak élni”. D. Integrációs teszt 1. A több modulból, alkalmazási részrendszerből álló szoftverek komponensei között összhangot bizonyító tesztelés. E. Információrendszer elfogadhatósági teszt 1. Annak a bevizsgálást jelenti, hogy az adott szoftver és hardver környezeben a rendszer képes együtt élni a többi alkalmazással és szoftverrel és nem okoz károkat az információrendszerek erőforrásanaik, nem rontja lényegesen más rendszerek teljesítményét és rendelkezésre állását. A tesztelendő rendszerben talált hibák kijavítása után a módosított rendszerre meg kell ismételni a teszt eljárást. I. Átvételi forgatókönyv A. egy részleg a szoftver rendszer átvehetőségére egy kezdeti tesztet hajt végre, amely nem teljes és nem is kimerítő. A rendszer előre rögzített specifikus tevékenységeire koncentrál. Ez nem helyettesíti a többi tesztet, hanem csak egy korlátozott rendszer értékelést tesz lehetővé. II. Rendszerelem teszt A. Az egyedi programok és modulok tesztje. Több olyan kidolgozott teszt esetet használnak erre a célra, amely az elemek procedurális vezérlésének ellenőrzésére szolgálnak. Ennek azt kell bizonyítania, hogy a programok belső struktúrája megfelel a követelményspecifikációnak. III. Interfész (kapcsoló felületek) tesztelése: A. Azokat a rendszerelemeket vizsgálják, amelyek kölcsönösen egymásnak adatokat adnak át. IV. Rendszer teszt A. Egy sor teszt eljárást kell tervezni erre, hogy a módosított program helyesen kommunikál a többi rendszer alkotórésszel. Ezt a feladatot a rendszer karbantaartására kijelölt csoport végzi általában. Ez a teszt a következő részekből áll: 1. Helyreállítási teszt – A szoftver vagy hardver meghibásodás után a rendszer visszaállítható-e a hibát megelőző állapotra. 2. Biztonsági teszt – Az új vagy módosított rendszert meg kell vizsgálni, hogy tartalmazza a szükséges jogosultsági rendszert, és nem 29
hozott be semmi olyan elemet, ami biztonsági szempontból lyuknak minősülne, és esetleg más rendszereket is veszélyeztetne. 3. Munkaterhelés / mennyiségi teszt – Az alkalmazási rendszert nagy mennyiségű adatokkal kell terhelni úgy, mintha csúcsterheléssel működne azért, hogy a csúcsidőkben várható viselkedését lehessen vizsgálni. 4. Teljesítmény teszt – A rendszer teljesítményét a nem-funkcionális követelményekben előírt teljesítmény szintekhez, más rendszerek teljesítményéhez viszonyítva kell elemezni, valamilyen jól definiált norma rendszer alapján. 5. Funkcionális teszt – A rendszer teszteléshez hasonló eljárás, amelyben azt ellenőrzik le, hogy a funkciók a követelményspecifikációban előírt részletes igényeknek megfelelően működnek-e. A két fázis tartalmaz általában az alfa tesztet (tesztelendő rendszer) és a béta tesztet (üzemi rendszer üzemi próba). 6. Regressió teszt – A teszt forgatókönyvek meghatározott részének újra futtatása azért, hogy ellenőrizzék a változtatások és javítások nem hoztak be új hibákat, vagy nem kívánatos mellékhatásokat. A teszt adatoknak a regresszió tesztnél és az eredeti tesztnél meg kell egyezniük. 7. Párhuzamos teszt – Az adatokat két rendszerbe rögzítik: a módosított és az alternatív rendszerbe (lehetőleg az eredeti rendszerbe) és össze vetik az eredményeket. II.4.1 Tesztelést segítő eszközök A projekt informatikai ellenőrzését, auditálását (akár belső akár külső szervezet, személy), a kifejlesztett rendszer működése helyességének bevizsgálását automatizált tesztelési eszközökkel is lehet segíteni. Léteznek tesztadat generátorok, audit szoftverek, (különösen a pénzügyi rendszerek esetében.), amelyek feltárják, hogy a program könyvtárakat mikor módosították, ellenőrzik a belső rendszer táblázatokat, stb. A számítógéppel segített strukturált tesztelési eljárások javítják az alkalmazás és rendszer szintű tesztek teljességét és pontosságát. Informatikai ellenőrzési szempontból a tesztelési szakaszban érintett területek a következők: • A tesztelési tervek vajon teljesek-e; • A teszt-esetek terjedelme lefedi-e a teljes rendszert; • A teszt-esetek dokumentáltságának mértéke, teljessége. • A teszt eredmények dokumentáltsága. • A fejlesztő csoportok által végrehajtott tesztelési eljárások között van-e összhang, nincsenek-e ellentmondásban. • A tesztelési eljárások valóban az alkalmazási rendszer által támasztott követelményeket vizsgálják-e be. • Minőségi rendszert csak minőségi tesztelési eljárásokkal lehet előállítani. II.4.2 Bevizsgálás, minőségellenőrzés A terv és program kód formális átvizsgálása és minőségi szemlézése esetében a rendellenességek eltávolításának hatékonysága lényegesen magasabb mint a szoftver tesztelésnél. A terv minden egyes formális átvizsgálása a létező hibák 65 százalékát feltárja és eltávolítja. 30
A program kód minden egyes formális átvizsgálása a létező hibák 60 százalékát feltárja és eltávolítja. Ez mutatja azt, hogy miért használják, az olyan szoftver fejlesztő szervezetek a tesztelést megelőzően a terv és a programkód formális átvizsgálását és minőségi szemlézését, amelyek 95 százalékos kumulált rendellenesség eltávolítás hatékonysággal dicsekedhetnek. Ráadásul a formális átvizsgálás viszonylag nem drága, és olyan drámai hatása van a tesztelési sebesség felgyorsulására és a karbantartási költségek csökkenésére, hogy a legjobb megtérülési mutatóval dicsekedhet az összes szoftver technológiai eszköz közül. II.5
Hibák kategorizálási lehetőségei
II.5.1 Hibák kategorizálásának egy lehetséges módja −
A. típusú: a specifikációtól való eltérés, annak megsértése ide értve, de nem kizárólagosan a rendszer leállást okozó hibát, funkcionálisan helytelen működést (az elfogadott specifikációtól való eltérést), pl. a függetlenül számított és a program működése során megfigyelt számítási eredmények eltérését, stb. A rendszer elfogadhatóságának feltétele, hogy az ilyen típusú hibáktól mentes legyen. B. típusú hiba: A felmerülő hiba nem akadályozza a program többi − részének helyes működését, nem akadályozza a tesztelés továbbfolytatását, a munkafolyamatok előírt logikájának, a kimenetek helyességének leellenőrzését. Ha a rendszer nem tartalmaz „túl” sok (továbbiakban meghatározandó mértékű) ilyen hibát akkor a rendszer feltételekkel elfogadható legyen. C. típusú hiba: kozmetikai jellegű hiba, ami tipikusan a − rendszerfelületen fordul elő, pl. képernyő tervezési probléma, helyesírási vagy betű megjelenítési probléma. D. típusú hiba: Az elfogadott rendszer specifikációt meghaladó − igény, ami pl. lehet esetleg új funkció megfogalmazása, létező és specifikált funkció működésének módosítása a kölcsönösen elfogadott rendszer specifikációban, előírásban rögzítettől eltérő módon, stb. E. típusú hiba: A hiba A., B., vagy D. kategóriába tartozik, azonban a − felhasználói útmutatóban, kézikönyvben leírt módon a hibás működés megkerülhető, fennállása a rendszer funkcionális és nem- funkcionális tulajdonságait nem károsítja, az utasítások betartásával normál üzemmód folytatható és fenntartható. II.5.2 Hibák kategorizálásának egy másik módja Kategória 1. Mérsékelt
2. Közepes
Példa Helyesírási hibák
Eljárás Nem kell vele foglalkozni; vagy, A következő jelentősebben módosított változat kibocsátásánál javítani kell. Félre vezető vagy Nem kell vele foglalkozni; fölösleges információ vagy, A következő jelentősebben módosított változat kibocsátásánál javítani kell. 31
Kategória 3. Bosszantó
Eljárás A következő jelentősebben módosított változat kibocsátásánál javítani kell. 4. Zavaró Néhány tranzakció A következő jelentősebben változat feldolgozása helytelen, módosított alkalmanként az egyik kibocsátásánál javítani kell. modul, a hiba miatt összeomlik, „elszáll”. 5. Súlyos Tranzakciók illetve A következő jelentősebben eredményeik elvesznek módosított változat kibocsátásánál javítani kell. VAGY, Lehet, hogy azonnali javítást igényel és új változat kibocsátását 6. Nagyon súlyos Rendszeresen az egyik Azonnal kiküszöbölendő. program modul, a hibája miatt, összeomlik, „elszáll”. 7. Rendkívül súlyos Gyakori, „nagyon súlyos” Azonnal kiküszöbölendő. hibák 8. Elviselhetetlenül súlyos Adatbázis tartalmának Azonnal kiküszöbölendő. sérülése 9. Katasztrofális Gyakori a teljes Azonnal kiküszöbölendő. rendszerösszeomlása, nem lehet újra indítani, a rendszer használhatatlan. 10. Fertőző A „katasztrofális” hibák Azonnal kiküszöbölendő. más rendszerek meghibásodását okozzák
II.6
Példa Csonkolt szövegrészek
A tesztelési tervek tartalomjegyzékei
A Vállalkozó telephelyén végzett mennyiségi, funkcionális bevizsgálásra és a Megrendelő telephelyé végzendő minőségi, felhasználói szintű, pénzügyi bevizsgálásra terveket kell készíteni. A tesztelési tervek az erre a szakaszra vonatkozó szakasztervek minőségi terv részeként benyújthatók. II.6.1 A mennyiségi, funkcionális tesztelés tervének tartalomjegyzéke 1. A (szoftver) alkalmazási rendszer aktuális verziójának 1.1. megnevezése 1.2. változat száma, azonosítója 2. A bevizsgálás kiterjedésének meghatározása 3. A bevizsgálásnál alkalmazott előfeltételek, feltételezések (pl. teszt adatok, stb.) 4. A funkcionális bevizsgálás megkezdhetőségének feltétel rendszere 4.1. Azon funkciók (funkcionális követelmények) listája, amelyek vizsgálatára sor kerül 4.2. A vizsgálat eredményeinek feljegyzése
32
4.3. Az ismert hibák és a rendszer használhatóságát biztosító lehetséges megkerülésük 5. A bevizsgáláshoz szükséges további erőforrás igények ( a szerződésben, szakasztervben, vagy egyéb hivatalos megállapodásban rögzítetteket meghaladó) 5.1. Hardver a. Mit b. Mikor c. Milyen időtartamra 5.2. Szoftver a. Mit b. Mikor c. Milyen időtartamra 5.3. A bevizsgálást végző szakemberek a. Megnevezése b. Mikor c. Milyen időtartamra 6. Külső feltételek biztosítása 6.1. Dokumentáció 6.2. Személyek rendelkezésre állása (Megrendelő, szerviz, stb.) 6.3. Egyéb termékek 7. Ütemterv 7.1. Legjelentősebb feladatok (kezdő / vég dátum) 7.2. feladatonként az időigény 8. A bevizsgálandó funkciók 8.1. Bemeneti adatok 8.2. Kimeneti adatok 8.3. Az eredmények kiértékelésének módja 9. A nem vizsgálandó funkciók (indoklással) 10. A vizsgálandó rendszertulajdonságok 10.1. Rendszer teljesítmény (performancia) 10.2. A rendszer használhatósága 10.3. A rendszer visszaállíthatósága 10.4. A rendszer üzembehelyezhetősége 10.5. A felhasználói dokumentáció 11. A bevizsgálási jelentés 11.1. Azonosító szám 11.2. A vizsgált funkciók, tulajdonságok felsorolása 11.3. A vizsgáló személy(ek) 11.4. Dátum, időpont 11.5. A azon feltételek, melyek fennállása mellett a vizsgálat lefolyt 11.6. A vizsgálat eredménye (pl. könnyen használható, korlátok vannak, stb.) 11.7. Pozitív megjegyzések 11.8. A feljavítandó területek 11.9. A problémák, kifogások jelzése a. A minőségi, felhasználói, pénzügyi teszt előtt kijavítandó hibák b. A minőségi, felhasználói, pénzügyi teszt után kijavítandó hibák 11.10. A kiértékelő összefoglalója II.6.2 A minőségi, felhasználói teszt tervének tartalomjegyzéke 1. A vizsgálat célkitűzése 33
2. 3.
4.
5. 6.
7. 8. 9.
1.1. Hossza, időtartama 1.2. Általános célok A bevizsgálásnál alkalmazott előfeltételek, feltételezések (pl. teszt adatok, stb.) A bevizsgálásra használandó telephelyek 3.1. A bevizsgálásra használandó telephelyek azonosítása (A Vállalkozó hatáskörében) a. Miért ezt választották (indoklás) b. Mit nyújt az adott telephely c. A bevizsgálás kezdete és vége d. Infrastruktúra irányítás, rendszerfelügyelet van-e e. A bevizsgálási helyszínek száma 3.2. A bevizsgálásra használandó telephelyek azonosítása (A Megrendelő hatáskörében) a. Miért ezt választották (indoklás) b. Mit nyújt az adott telephely c. A bevizsgálás kezdete és vége d. Infrastruktúra irányítás, rendszerfelügyelet van-e e. A bevizsgálási helyszínek száma Melyik telephelyen mit fognak vizsgálni (táblázatos, mátrix formában megadható) 4.1. A rendszer hordozhatósága (pl . Win NT, Win 95, Win 98) 4.2. Rendszer teljesítmény (performancia, válaszidők, feldolgozási mennyiségek, stb) 4.3. Megbízhatóság 4.4. Használhatóság 4.5. Felhasználó támogatásának, segítésének szintjei, karbantartási szolgáltatások szintje 4.6. Az üzem behelyezés, telepítés egyszerűsége 4.7. A szabványok kielégítése 4.8. Dokumentáció 4.9. A tervezési logika A Vállalkozó által a bevizsgáláshoz rendelkezésre bocsátott erőforrások 5.1. A Megrendelő telephelyén 5.2. A Vállalkozó telephelyén A rendszer telepítése, üzembe helyezése előtt 6.1. A Megrendelő telephelyén a. A telephely(ek) előkészítése b. Biztonsági kérdések c. A telephely megfelelőségének ellenőrzésére szolgáló lista1 d. Probléma jelentési mechanizmus A minőségi, felhasználói, pénzügyi bevizsgálásról készítendő heti műszaki, informatikai jelentés A rendszeres üzemeltetés megkezdhetőségének feltétel rendszere A minőségi, felhasználói, pénzügyi bevizsgálásról készítendő összefoglaló jelentés: A telepítésnél nyújtott támogatás: A Megrendelő és a fejlesztő értékelése a telepítésnél nyújtott informatikai, szakmai támogatásról.
1
A lista a következőket tartalmazhatja (példálózó, de nem kizárólagos jelleggel): az adott telephely konfigurációs követelményeit, a rendszer telepítéséhez szükséges paraméterek, adatok meghatározását, a telepített rendszer tervének, működésének logikájából fakadó igényeket, stb.
34
Az üzemi próba problémái: A minőségi, felhasználói, pénzügyi bevizsgálás során felmerült kérdések, javítandó hibák, problémák. Dokumentáció: A végfelhasználók reagálása rendszerrel együtt leszállított a felhasználói dokumentációra, útmutatókra. Beleértve az esetleges, a bevizsgálás alatt végrehajtott illetve a későbbiekben végrehajtandó javasolt módosításokat. Humán erőforrások: A minőségi, felhasználói, pénzügyi bevizsgálást befolyásoló személyi kérdések, rendelkezésre állás. Továbbá a rendszer kielégítő módon működik-e a leendő felhasználók szemszögéből. A kifogások, problémák, hibák értékelése, a javítások fontossági és sürgősségi sorrendbe állítása, a problémák esetleges megkerülhetőségének rögzítése, a probléma jelentések jóváhagyása, érvényességük igazolása Egyebek.
35
II.7
Kockázat elemzés
Az alkalmazási rendszer fejlesztési projektek fontos eleme a megelőző illetve folyamatos kockázat elemzés. Az EU támogatásával kifejlesztett módszertanra és eszközre vonatkozólag a következő helyen lehet további információkat találni. http://www.riskdriver.com/riskmantool (2001-április. 18) Néhány egyszerűbb táblázat kitöltésével és elemzésével szintén elég jó eredményre lehet jutni, ezekre a következő szakaszokban közlünk példákat. II.7.1 A közbeszerzés keretében beszerzett alkalmazási rendszer kockázatának és bonyolultságának jellemzése Célterület
Bonyolultság
Információ rendszer
Szereplők heterogenitása Célterület mérete Elosztottság mértéke Információk bonyolultsága Működési folyamatok bonyolultsága
egyszerű
Számítógép
Adatok bonyolultsága
rendszer
Funkciók bonyolultsága Nem-funkcionális követelmények bonyolultsága Számítógép rendszer másolatainak száma Céltechnológia bonyolultsága
II.7.2 A közbeszerzés keretében bonyolultságának jellemzése
közepes
bonyolult
Bizonytalanság
biztos
közepes
bizonytalan
Szereplők hozzáállása Szereplők képessége Környezet stabilitása Információ formalizáltsága Működési folyamatok formalizáltsága Információs és működési folyamatok stabilitása Információ rendszer specifikussága Meglévő rendszer megérthetősége Stratégiai fontosság Szervezeti változások fontossága Követelmények megléte, világossága és stabilitása A létező specifikációk minősége Technológiai változások fontossága
Céltechnológia újdonsága
végrehajtott projekt kockázatának és
36
Projekt tartomány
Bonyolultság
Projekt feladat
Projekt mérete
egyszerű
közepes
bonyolult
Alvállalkozók száma Kapcsoló felületek száma más IR-adaptációkhoz
Projekt szereplők Projekt technológia
biztos
köze pes
bizony talan
IR-adaptáció újdonsága Ütemtervek alkalmassága Költségvetés alkalmassága Alvállalkozóktól való függés Más IR-adaptációktól való függés
Migráció bonyolultsága
Projekt szerkezet
Bizonytalanság
Vevő-szállító kontextus formalizáltsága Projekt csapat képességei Fejlesztési technológia újdonsága Alkalmas fejlesztési technológia rendelkezésre állása
Projekt szereplők száma Fejlesztési technológia bonyolultsága
II.7.3 Beruházási értékre számított kockázat elemzés
Projekt kockázat elemzési lap Vállalkozás díjra / projekt költségre vetítve
KATEGÓRIA A Projekt költség
ÉRTÉK
FORMULA KOCK.EGYSÉG 1 000 000 Ft-ként normálva 1 emberévenként
B Fejlesztési idő (emberévekben) C Fejlesztési idő (években, összes) D Felhasználó egységek száma E Szerződő felek száma F Telepítési helyek száma G Képernyők száma H Új a technológia a I vagy N szervezet számára ? I A felhasználók I vagy N tapasztaltak ? J Ismert funkcióról van szó ? I vagy N K Új-e a fejlesztési módszer I vagy N ? L Milyen a funkció E, K, B (egyszerű, kö-zepes, bonyolult) ? M Vagyoni jellegű szellemi FN, F,N jogok átadása: FN (feltétel nélkül), F (feltétellel), N (Nem)
emberévek/évek D értéke E értéke F/2 értéke G értéke I = A értéke, N = 0 I = 0, N = A/5 értéke I = 0, N = A/5 értéke I = A/5 értéke, N = 0 B = A/2, K = A/5, E= 0 FN=0, F=A/2, N=A
37
N Követési hajlandóság: FN FN, F, N (feltétel nélkül), F (feltétellel), N (Nem) O Országos hálózat I vagy N
FN=0, F=A/2, N=A I = 0, N = A/5 értéke ÖSSZESEN (A-tól O-ig) O/2 értéke
KOCKÁZATI ÉRTÉK
38
III. Egyéb projektszerepek III.1
A projektvezetőség feladat- és hatásköre
A projektvezetőség fontosabb feladatai a következők: A projekt kezdetén: ♣ Összeveti a projekt alapító okiratot (mely, egyebek között, tartalmazza a projekt rövid leírását, az ún. hivatkozási alapot, és viszonyát más projektekhez) a projektnek a finanszírozó testület által meghatározott kiterjedésével, határaival, és adminisztratív /üzleti céljaival. ♣ Meghatározza a projekt olyan külső feltételeit, mint például a konfigurációkezelés és a minőségbiztosítás. ♣ Kinevezi a személyeket a projektirányító és szakaszirányító szerepkörökbe, meghatározza feladat- és hatáskörüket, felelősségüket és a követendő célokat. ♣ Kinevezi a projektbiztosító csoport tagjait, kijelöli feladat- és hatáskörüket, felelősségüket és céljaikat. ♣ Áttekinti és jóváhagyja a projekt szakmai (informatikai) és erőforrástervét. ♣ Áttekinti és jóváhagyja az első szakasz szakmai (informatikai) és erőforrástervét. ♣ Jóváhagyja az erőforrásoknak feladatokhoz rendelését. ♣ Áttekinti és jóváhagyja a projektalapító okiratot. ♣ Engedélyt ad a projekt indítására. A vezetőség feladatai a projekt menete során: ♣ Kiértékeli és jóváhagyja a szakaszok szakmai (informatikai) és erőforrástervét. ♣ Kiértékeli és jóváhagyja a helyreigazítási terveket. ♣ Levezeti a szakaszközi és szakaszvégi értékeléseket. ♣ Engedélyezi az egyes szakaszok megkezdését, vagy a projekt leállítását javasolja. ♣ Aláírásukkal hitelesítik és hagyják jóvá a szakaszok befejeződését. Feladatok a projekt végén: ♣ Meggyőződik a termékek teljességéről és átadásáról. ♣ Jóváhagyja a projekt lezárását. ♣ Formálisan elfogadja a projektértékelő értekezlet eredményét. ♣ Megszervezi a kivitelezés utáni értékelést. A projekt során folyamatosan: ♣ Általános irányítást és útmutatást nyújt a projekt résztvevőinek. ♣ Biztosítja, hogy a projekt az elfogadott projektirányítási módszer szerint haladjon ( kormányzati ajánlás: PRINCE). ♣ Megbizonyosodik arról, hogy a projekt folyamatosan teljesíti az informatikai beruházások értékállóságával szemben támasztott követelményeket. ♣ Jelentéseket készít a projektfinanszírozó testület és egyéb érdekelt vezető testületek számára. Általános megjegyzések: A projektvezetés tagjainak megfelelő felhatalmazással és tekintéllyel kell rendelkezniük ahhoz, hogy végrehajthassák az előttük álló feladatokat, szem előtt tartva a projekt méretét és jellegét.
39
III.2
A projektvezetőségen belüli szerepkörök
III.2.1 Ügyvezető (elnök) Alapfeladatok: Biztosítania kell, hogy a fejlesztés alatt álló rendszer a várt előnyöket nyújtsa, és a projekt a finanszírozók által jóváhagyott költség- és időkereten belül maradjon. Elvégzendő feladatok • Szervezze és irányítsa a projektvezetőség találkozóit. • Biztosítsa a projektirányítói és szakaszirányítói szerepkörök betöltését, valamint a kapcsolódó feladatok és célok meghatározását. • Biztosítsa az adminisztratív koordinátornak, a szakmai /informatikai felelősnek (koordinátornak) és a felhasználói koordinátornak a kinevezését, valamint a kapcsolódó feladatok és célok meghatározását. • Jóváhagyja a kiadásokat és meghatározza a tűréshatárokat. • Jóváhagyja a projektszintű és szakaszszintű erőforrásterveket. • Biztosítja, hogy a tervek a projektfinanszírozó testület által meghatározott informatikai stratégia és feltételek (pl. ellenőrzési és beszámolási követelmények) figyelembevételével készüljenek, és az ezekben történt változások a projektben tükröződjenek. • Igazolja a szakaszközi és szakaszvégi értékelés sikeres befejeződését, meggyőződve arról, hogy a projekt a költségtervével továbbra is összhangban van. • Igazolja a projektzáró értekezlet sikeres befejeződését. • Előírások szerint rendszeresen jelentéseket készít a projektet finanszírozó testület számára. • A projekt kielégítő eredménnyel történő befejeződésekor aláírja az adminisztratív / üzleti teljesítési jegyzőkönyvet, és szükség esetén az információtechnológiai biztonsági teljesítési jegyzőkönyvet. • Ajánlásokat tesz a lehetséges intézkedésekre a projektfinanszírozó testület számára arra az esetre, ha a projekt átlépné valamelyik megállapított tűréshatárát (pl. befejezni a projektet, több forrást biztosítani, szűkebbre vonni a projekt kiterjedését, vagy hosszabb teljesítési időt meghatározni). • Előkészíti a rendszer kivitelezés utáni értékelését. • Behatóan tájékoztatja és tanácsokkal segíti a felső szintű vezetőket a projektet érintő ügyekben. Irányítja: • az összes projektet irányító személyt. Alárendeltje: • a projektfinanszírozó testületnek és bizonyos felső szintű vezetőknek. Előírt tudás és gyakorlat: • Alapos ismerete: ♦ Az általános információtechnológiai stratégiának. ♦ A hosszú távú stratégiának, az adott projekt terület szempontjából. ♦ Az információtechnológiai rendszerek komponenseinek, alap- fogalmainak. ♦ A PRINCE módszertan felső szintű vezetők számára szükséges ismerete. ♦ Az ügyvezető igazgatói teendőknek. • Ismerete: ♦ Az információtechnológia biztonsági követelményeinek ♦ A kockázatelemzési és kezelési módszereknek.
40
III.2.2 Felhasználói képviselő Alapfeladatok A projektben érintett összes felhasználói osztály érdekeit képviseli, és összehasonlítja a projekt előrehaladását a felhasználók vezetőinek követelményeivel. Elvégzendő feladatok • Egyetértési joga van azon termékek minőségi követelményeit illetően, melyek a felhasználókat közvetlenül érintik (ilyen például a felhasználói követelmények jegyzéke), valamint az üzembe helyezés és kiképzés célkitűzéseiben. • Jóváhagyja a felhasználók által használt, vagy őket közvetlenül érintő termékek termékleírását. • A felhasználók oldaláról jóváhagyja a felhasználójegyzéket és az átvétel feltételeit. • Biztosítja, hogy a humán erőforrásokkal való gazdálkodás szempontjai a projekt kezdetétől érvényesüljenek a tervekben, és a projekt során végig figyelembe vegyék ( a megrendelő részéről a leendő felhasználók ütemezett rendelkezésre állásának biztosítása). • Feloldja a felhasználói követelmények és prioritások ellentmondásait. • A projekt igényeinek megfelelően bocsátja rendelkezésre a felhasználói erőforrásokat. • Részt vesz a szakaszértékeléseken és a projektzáró értekezleten, és a felhasználói osztályok nevében írja alá a jegyzőkönyveket. • Jóváhagyja az üzembe helyezési és átállási terveket. • Jóváhagyja a felhasználók oktatási és kiképzési tervét. • Aláírja a felhasználói teljesítési jegyzőkönyvet az üzembe helyezés végén. • A szakmai képviselővel együtt aláírja az üzemeltetési teljesítési jegyzőkönyvet az üzembe helyezés végén. • Behatóan tájékoztatja és tanácsokkal segíti a felhasználók vezetőit a projektet érintő ügyekben. • Gondoskodik róla, hogy a felhasználói koordinátor rendelkezzen a napi feladatok intézéséhez szükséges információkkal. • Megvizsgálja a váratlan szakmai (informatikai) nehézségek, a tervtől való eltérések hatását felhasználókra. Felettese: • minden érintett felhasználói osztálynak. • a felhasználói koordinátornak. Alárendeltje: • a projektvezetőség nevében eljáró ügyvezetőnek ( a projektvezetőség elnökének) Előírt tudás és gyakorlat: • Az érintett felhasználói, működési területek vezetői és vezetési problémáinak széleskörű ismerete. • Az információ-technológia ismerete a végfelhasználó szempontjából. • A minőség és a minőségirányítás alapfogalmainak alapos ismerete. • A leendő rendszer működtetési, üzemeltetési elképzeléseinek ismerete. • A PRINCE módszertan felső szintű vezetők számára szükséges ismerete. • Az emberi tényezők, a humán erőforrások és a projekt kimenetelének sikerességét és eredményességét befolyásoló hatásaik világos megértése. • A változás kezelés lényegének és a rendszer fejlesztési folyamatban a felhasználók aktív részvétele fontosságának megértése.
41
• Az információ-technológiával kapcsolatos területen szerzett gyakorlati tapasztalat. III.2.3 Vállalkozó képviselője A vállalkozó képviselőjének feladata az, hogy a termék megtervezésére és kifejlesztésére előterjesztett javaslatok reálisak legyenek, abban az értelemben, hogy a felhasználók képviselője által igényelt eredményeket elérjék azon idő és költség korlátok között, amelyért az elnök felelős. Ennek a szerep képviseli azoknak az érdekeit, akik a termék megtervezésével, kifejlesztésével, beszerzésével, megvalósításával, üzemeltetésével és karbantartásával foglalkoznak. A vállalkozó képviselőjét el kell látni a szükséges felhatalmazásokkal ahhoz, hogy a vállalkozó erőforrásai fölött a projekthez igényelt mértékben rendelkezzék. III.2.4 Szakmai (informatikai) képviselő Alapfeladatok A fejlesztő és üzemeltető szervezetek, szervezeti egységek érdekeit képviseli a projektvezetőségben és nyomon követi a projekt előrehaladását, hogy vajon összhangban van-e a szakmai (informatikai) vezetés követelményeivel. Elvégzendő feladatok • A szakmai, műszaki tevékenységek célkitűzéseit formálisan jóváhagyja (pl. a rendszer tervezését, fejlesztését, tesztelését). • A szakmai (informatikai) termékek termék leírását formálisan elfogadja. • A szükséges szakmai erőforrások rendelkezésre bocsátásáról gondoskodik. • A szakmai prioritások és az erőforrások közti konfliktusokban döntőbíróként lép fel és gondoskodik a megoldásról. • A projekt és a szakasz szakmai tervét aláírásával jóváhagyja. • A szakasz- és projektzáró értekezletek résztvevője és a fejlesztő és az üzemeltető szervezetek, szervezeti egységek nevében írja alá a jegyzőkönyveket. • Előkészíti a rendszer átvételi (teljesítési) jegyzőkönyvet és aláírásával igazolja a rendszer tesztelés sikeres lezárulását. • A felhasználói képviselővel közösen igazolják a rendszer sikeres üzembeállítását az üzemeltetési teljesítési jegyzőkönyv aláírásával. • Tájékoztatja a nem szakmai (informatikai) vezetést a projekt műszaki aspektusairól. • A szakmai felelős (vagy koordinátor) megfelelő tájékoztatásáról és informáltságáról gondoskodik, amire a napi feladatok intézéséhez szüksége van. • Utasítja: • A rendszer fejlesztést végző szervezeti egység (ek)et. • A rendszer üzemeltetést végző szervezeti egység (ek)et. • A szakmai felelőst (vagy koordinátort) • Utasítást kap: • A projekt ügyvezetőtől ( a projektvezetőség elnökétől). • Előírt tudás és gyakorlat: • Széleskörű informatikai és információ-technológiai irányítási tapasztalat. • A felhasználói működési területek alapos ismerete. • A cég egészére vonatkozó informatikai stratégia alapos megértése. • A leendő rendszer felhasználókra gyakorolt hatásának és a szükséges műszaki feltételeknek az alapos megértése. • A PRINCE módszertan felső szintű vezetők számára szükséges ismerete.
42
• •
A vonatkozó minőségi és szakmai (informatikai), műszaki szabványoknak és előírásoknak az alapos ismerete. A felhasználók problémáinak elegendő mélységű ismerete.
III.3
Programigazgató
III.4
Programfelelősök
III.4.1 Programirányító III.4.2 Szervezetfejlesztésért felelős személy III.4.3 Műszaki, informatikai felelős
43
IV. Minimum dokumentációs szabvány (ISO 6592) A sajátosságok leírása készülhet bármilyen nemzetközileg elfogadott módszertanban (strukturált, objektum-orientált, vagy rendszer szemléletű), bármilyen elektronikus eszközben, melyet a megrendelő olvasni tud és később felhasználni (CASE eszközök, rajzoló programok, szövegszerkesztők). Ösztönözni kell az elektronikus formában való dokumentum készítést és átadást. Az alkalmazási rendszerek dokumentálásánál az ISO 6592-es szabvány előírásait kell szem előtt tartani. Az esetlegesen előírt vagy kiválasztott módszertan a szabvány előírásain túl menően, pontosabb, konkrétabb szabályokat, mintákat, „dokumentációs szabványt” tartalmazzon. Az ISO 6592 mint nemzetközileg elfogadott szabványt, az Európai Unióban is érvényesített és érvényesülő szabványt minimum előírásként elfogadni célszerű. E szabványból adódó leglényegesebb követelmények a következők (esetenként egyéb módszertanokból hozzáemelt kiegészítésekkel). IV.1
Megvalósíthatósági tanulmány A tanulmánynak több célja van: • feljegyzi a vezetés döntéseit a további munka lehetőségeiről, beleértve a javasolt rendszer megszüntetését, kiterjedésének megváltoztatását, felbontását, illetve összevonását másik rendszerekkel, • indoklási alapul szolgál a vezetésnek a teljes körű vizsgálat erőforrásainak kijelöléséhez (és kiindulási anyaga a kialakítandó alkalmazásnak), • minden teljes körű vizsgálat részére információt nyújt a döntésekről, feltételezésekről, becslésekről, felhasználói követelményekről és vázlatos alternatívákról, és a kiválasztott vagy előnyben részesített megoldásról. • vázlatos projekttervet ad minden teljes körű vizsgálat irányításához, • feljegyzi az elemző csoport eredményeit, a hivatkozási alapoknak megfelelően, valamint bizonyítja az elemző csoport munkáját.
Tartalom 1. rész: Bevezetés: az elemzés indokai (környezet, háttér, jelenlegi szituáció) • hivatkozási alapok • az elemzés célkitűzései • az elemzés kiterjedése • korlátok (pénzügyi és műszaki) • teljesítés dátuma • konzultáció • az elemzés irányítása 2. rész: Vezetői összefoglaló: • az ajánlott megoldás, • a megvizsgált és elvetett alternatívák, • a teljeskörű vizsgálat tervei, • a javasolt beszerzési út, • a rendszermegvalósítás tervei.
44
3. rész: Az elemzés irányításának módja és a költségek. 4. rész: A jelenlegi szervezeti működés és támogató információs rendszerei, leírva a jelenlegi helyzetet az elemzés alá vont területen, a következők szerint: • az üzleti/működési célkitűzések, • a jelenleg létező folyamatok és eljárások, • a működési terület szervezete, a különböző szerepek és felelősségi körök, • a jelenlegi és a lehetséges erős és gyenge oldalak, • kapcsolatok más működési területekkel és szervezetekkel, • létező információs rendszerek által nyújtott támogatás, részletezve a támogatott illetve nem támogatott funkciókat, erősségeket és gyengéket, a technológiai lehetőségeket és korlátokat. 5. rész: A szervezet által igényelt jövőbeli információs rendszertámogatás: • a rendszer információs rendszerekre vonatkozó stratégián belüli helyének leírása, • az igényelt rendszer kiterjedésének és fiunkcionalitásának áttekintése, • a követelmények részletei mérhető formában, • a földrajzilag szétszórt elhelyezkedés hatása az információs támogatásra, • a javasolt rendszertől elvárt szolgáltatási szint. 6. rész: Javasolt rendszer, leírva a fenti követelmények kielégítésének módját: • Funkcionális leírás: szöveges áttekintés a logikai rendszerről, a választott rendszerszervezési alternatívára alapozva, továbbá • biztonság; • kapcsoló felületek; • adatáramlás; • alternatív technológiai lehetőségek vázlata, a szükséges technikai keretekkel együtt, • az adatbevitel ellenőrzésének mechanizmusai annak érdekében, hogy az előírt adat helyesség, érvényesség elérését biztosítani lehessen; • manuális, nem számítógépes eljárások; • a rendszer fejlődésének lehetőségeinek biztosítása: • adat mennyiség, volumen növekedés; • új funkciók beillesztése; • A rendszer teljesítménye, feldolgozások ütemezése (válaszidők, áteresztőképesség) • Igényelt: • fejlesztői és felhasználói erőforrások; • hardver;
45
• szoftver; • elhelyezés. • a csoport javaslatainak előnyei és hátrányai. 7. rész: Pénzügyi becslések, összefoglalva a javasolt rendszer költségeit, és összefoglalva a várható hasznokat a jelenlegi gyenge pontokhoz képest. • Forintosítható költségek; • hasznok, előnyök. 8. rész: Projektterv minden javasolt intézkedéshez, beleértve az erőforrás-igényeket és a várható megvalósítási időtávot, javaslatot téve a fejlesztés és megvalósítás irányítási szerkezetére is. • munkaerő igény, fejlesztő csoport; • kiképzés, oktatás; • A főbb tevékenységek ütemterve; • emberi erőforrások igénye; • hardver; • szoftver; • elhelyezés, építészeti megoldás. • A megvalósítás minőségi kérdései és az elfogadhatóság, átvehetőség kritériumai: • rendszer tesztelése; • állományok létrehozása, konvertálás; • a meglévő rendszerekkel összekapcsolás, összhangba hozás; • felhasználók kiképzése, oktatása; • emuláció (pilot, párhuzamos, üzemi próba, stb.); • a rendszerre való áttérés javasolt módja; • a szolgáltatások megváltoztatására javaslat; • minőség biztosítási követelmények ( pl. ISO 9000-3); • garanciális, szavatossági, jótállási és egyéb termék felelősségek; • a rendszer elfogadhatóságának és átvehetőségének kritérium rendszere. 9. rész: Következtetések és ajánlások. • Megvizsgált és elvetett alternatívák, kiemelve az elutasítás okait. IV.1.1 A teljes rendszer terve Ennek a szakasznak, és dokumentumnak az a feladata, hogy a kiválasztott rendszer tervét részletesen leírja. IV.2
A rendszerterv tanulmány, dokumentum (Logikai rendszerterv)
IV.2.1 Célkitűzései A rendszer tervének elég részletesnek kell lennie ahhoz, hogy:
46
a) a felhasználónak világos képet kell arról kapnia, hogy a rendszer mit fog csinálni (bemenő adatok, feldolgozás, kimenő adatok, tárolás, válaszidők, ütemezés, stb.); b) a felhasználó pontosan tudja, hogyan használja és működtesse a rendszert. c) azokat a szervezeti változások és egyéb adaptációs feladatokat is meghatározza, amelyek a rendszer megvalósításához és üzemeltetéséhez szükségesek, továbbá ezek a tevékenységek külön feladatként hajtandók végre; d) a funkcionális követelmények kielégítően részletezettek és egyértelműek azért, hogy a fejlesztés következő szakaszában a további tervezési dokumentumok kidolgozhatók legyenek. IV.2.2 Tervek (projekt, szakasz): a) b) c) d) e)
szervezet; ütemterv, határidők; jelentősebb erőforrás igények; minőségbiztosítás (ISO 9000-3); használandó szabványok.
IV.2.3 Költségek és hasznok: a) b) c) d) e)
fejlesztői költségek; üzembe helyezési költségek; kiképzési és oktatási költségek; folyamatos, állandó költségek; kézzelfogható (forintosítható) hasznok és egyéb, nem kézzel fogható előnyök.
IV.2.4 Rendszer leírás: a) az alkalmazási rendszer funkcionális átekintése; b) hardver igények; c) távközlési, kommunikációs igények (terminálok, vonalak, modemek, koncentrátorok, stb.) d) szoftver igények(programozási nyelvek, adatbázisok, operációs rendszerek); e) adatok leírása; f) adatfolyamok, (adatmennyiségek, átlagos és csúcs terhelés); g) az adatmennyiség növekedésére való felkészülés; h) az adatok helyességének, érvényességnek biztosítására ellenőrzési mechanizmusok (pl. pénzügyi és informatikai revizori szempontból, CISA, stb.) i) biztonság, rendszer összhangja, adatvédelem, fizikai biztonság, rendelkezésre állás; j) környezeti feltételek és áram igény (beleértve egyéb tartalékokat: hideg, meleg és forró, stb.); k) kapcsoló felületek más rendszerekhez (meglévőkhöz és tervezett, leendő rendszerekhez); l) ütemezési igények; m) további funkciókkal való bővíthetőségre való felkészítés; n) nem számítógépes, manuális eljárások;
47
IV.3 A megvalósítás minőségi kérdései és az elfogadhatóság, átvehetőség kritériumai: a) felhasználók kiképzése, oktatása; b) állományok létrehozása, konvertálás; c) rendszer tesztelése, teljesítmény mérés (válaszidők, áteresztőképesség) [ISO 9000-3, ISO 9126]; d) emuláció (pilot, párhuzamos, üzemi próba, stb.); e) a szolgáltatások megváltoztatására javaslat; f) a meglévő rendszerekkel összekapcsolás, összhangba hozás; g) a rendszerre való áttérés javasolt módja; h) minőség biztosítási követelmények ( pl. ISO 9000-3); i) garanciális, szavatossági, jótállási és egyéb termék felelősségek, ezek terjedelme; j) a rendszer elfogadhatóságának és átvehetőségének kritérium rendszere. IV.3.1 Támogató szolgáltatások a) Hiba esetén helyreállítás; b) karbantartási felelősség és garanciális feltételek; c) pótalkatrész, pót-egység biztosítása és mentési szolgáltatások.
és
IV.3.2 Az alkalmazási rendszer összefoglaló leírása a) b) c)
d)
probléma definíciója és megoldása; javaslatok; rendszer üzemeltetése: 1) emberi erőforrások; 2) hardver; 3) szoftver; 4) elhelyezés; 5) pénzügyi becslés; 6) biztonság; 7) ütemezés, szolgáltatási színvonal; terminológia jegyzék (új, vagy szokatlan kifejezések)
IV.3.3 Vezetői összefoglaló a) b) c) d) e) f) g)
emberi erőforrások; hardver; minőség biztosítási követelmények ( pl. ISO 9000-3); elhelyezés; költség becslés 1) a projekt következő szakaszára; 2) a teljes projektre; hasznok, előnyök becslése; ütemterv.
48
visszaállítási
IV.3.4 A rendszerterv (fizikai rendszerterv) Ennek a dokumentumnak az a célja, hogy a rendszer teljes tervét leírja, a következő elvek alapján: a) a rendszer mindegyik részében található olyan funkció, amelyet le kell írni; b) a teljes rendszer mindegyik funkciója tökéletesen leírható a részfunkcióin keresztül, azaz azok részletes leírásával és közöttük fennálló kapcsolatok megadásával, együttműködésük közlésével. A dokumentáció általában két szintet tartalmaz: − általános rendszerleírás; − rendszer alkotóelemek leírása. IV.3.5 Általános rendszerleírás Ennek a dokumentumnak a részletezettsége attól függ, hogy milyen követelményeket támasztottak a rendszerrel szemben. Ettől a dokumentációtól elvárható, hogy a rendszer használatát segítő, támogató dokumentációnak az alapja legyen. A következőkre kell ennek a dokumentációnak kitérnie: a) A projekt megnevezése; b) célok; c) a rendszer leírása (szövegesen és ábrákkal); 1) a részrendszerek meghatározása; 2) a kapcsoló felületek meghatározása a többi rendszerhez; d) biztonság; e) ellenőrzési mechanizmusok (beleértve a pénzügyi és informatikai revizori munka támogatását); f) üzemeltetési környezet; g) helyreállítási munkálatok; h) a rendszer üzemeltetéséhez szükséges segítő, támogató szolgáltatások; i) adat követelmények; j) tesztelési, bevizsgálási eljárások; k) a változtatási igények kezelésének eljárásai. IV.4
Rendszer alkotóelemek leírása Ez a dokumentum tartalmazza a részletes műszaki leírását (specifikációt) a programokról, az adatállományokról, és a manuális műveletekről. Ettől a dokumentációtól elvárható, hogy a rendszer használatát segítő, támogató dokumentációnak az alapja legyen.
IV.4.1 Program specifikációk Lsd. részletesen a tartalmi követelményeket ”IV.13 Számítógéprendszer funkció-ábrázolásának funkcionális sajátosságai”, valamint az adott programozási nyelvre fejlesztő környezetre elfogadott dokumentálási szabványokat. A program specifikációk a rendszer funkcióinak részletes, program kód szintű tervének alkalmas formalizmusban történő megadását jelenti, ami viszont nagyon sok technológiai feltételtől függ. Ennek a leírásnak a továbbfejlesztést, karbantartást. és módosítást lehetővé kell tenni, olyan módon is akár, hogy harmadik felet lehessen bevonni ezen feladatok ellátására. Ha az üzemeltető partner nem azonos a készítővel akkor a szokásos
49
karbantartási feladatoknak az ellátását, segítését, a a probléma megértését és feltárását gyorsítania kell. Ilyenek például: a továbbfejlesztés a tökéletesítés, a környezethez való jobb alkalmazkodás érdekében végzett fejelsztő munkák, a specifikációban meglévő hibák kiküszöbölése és az egyszerű program illetve rendszer együttmüködési ( operációs rendszer, alkalmazás fejlesztő környezet, alkalmazási rendszer között felbukkanó együttmüködési problémák) hibák felszámolása IV.4.2 Adatállomány és adatbázis specifikációk Lsd. részletesen a tartalmi követelményeket ”IV.12 Számítógéprendszer adatábrázolásának funkcionális sajátosságai” IV.4.3 Manuális eljárások leírása Lsd. részletesen a tartalmi követelményeket ”IV.11 Munkafolyamat-ábrázolás funkcionális sajátosságai” IV.5
A rendszert támogató dokumentáció
IV.5.1 Célkitűzés Miután a felhasználó elfogadta és átvette a rendszert, a rendszerrel kapcsolatos tevékenységeket kell ennek a dokumentációnak segítenie. A következő szempontokat öleli fel: a) a rendszer normális, hétköznapi használata; b) a hibák észlelése és kijavításuk; c) az esetleges módosítási és továbbfejlesztési, bővítési eljárások. A fentebb felsorolt tevékenységeket valószínűleg nem a fejlesztő csoport fogja végezni, ezért ezt a dokumentáció készítésekor figyelembe kell venni. IV.5.2 A rendszert támogató dokumentáció A tervezési és fejlesztési szakaszban végrehajtott változtatásokat ennek a dokumentációnak vissza kell tükrözni. a) Felhasználói kézikönyv Ennek a dokumentumnak tömören és világosan le kell írnia a felhasználók és a szállító jogait és kötelességeit, felelősségét. Például a következőket: 1) A felhasználó jogai közé tartozhat: • a rendszer használatáról szóló információkhoz való hozzáférhetőség; • a rendszer által előállított eredményekhez és az adatokban keletkezett hibák kijavításáról szóló információkhoz való hozzáférés; 2) A felhasználó felelőssége kiterjed: • a helyes bemeneti adatok előállítására; • a szállító tájékoztatására, ha bármilyen hibát észlel a rendszerben. 3) A szállító jogai közé tartozhat: • a leszállított rendszer felül vizsgálatának lehetősége;
50
•
b)
c)
d) e)
f)
a rendszer folyamatos tesztelhetősége azért, hogy a folyamatos helyes működés garantálható legyen; 4) A szállító felelőssége kiterjed: • a dokumentáció folyamatos karbantartása, az aktualitásának, naprakészségének megőrzése érdekében; • a felhalmozott felhasználói tapasztalatok eljuttatása az érdekeltekhez. Üzemeltetési kézikönyv Ennek a kézikönyvnek le kell írnia azt, hogy hogyan működtessék a rendszert a számítógépestül, valamint az egyéb kapcsolódó berendezésekkel együtt, a lehetséges összes üzemeltetési módozatban. Program leírás Mindegyik program célját, működését kell leírnia, beleértve például a matematikai képleteket és algoritmusokat, amiket esetlegesen használ, valamint a hiba kezelési eljárásokat, továbbá a program időzítési és ütemezési paramétereit. tartalmaznia kell a program listákat, a megjegyzésekkel ellátva. (Különösen hasznos a módosításoknál és bővítéseknél, tesztelésnél, teszt adatok és az eredmények elemzésénél). Adat kézikönyv Ennek a dokumentumnak a rendszer követelményekben előírt mértékig kell részletesen leírni a rendszer adatszerkezetét. A rendszer technikai, műszaki leírása Ennek a dokumentumnak képessé kell tennie a műszaki személyzetet arra, hogy megértse a rendszer működését, segítse a hiba feltárást és javítást, lehetővé a rendszer módosítását és bővítését. Rendszer változtatási napló Ennek a naplónak tartalmaznia kell, hogy milyen változtatásokat, mikor, miért, és ki végezte el és kitől kapott felhatalmazást.
IV.5.3 Megvalósítás utáni felülvizsgálat IV.5.4 Értékelő jelentés a) b) c) d) e) f)
Annak az elemzése, hogy vajon az eredeti rendszer célkitűzések helyesek voltak-e, milyen mértékben sikerült ezeket a gyakorlatban megvalósítani; a tovább javítási lehetőségek kiemelése; a jó gyakorlat elősegítése, terjesztése; az üzemeltetési problémák felismerése és elemzése; annak elemzése, hogy a megjelölt előnyöket illetve hasznokat elértéke; a leendő fejlesztések számára használható és érdekes tapasztalatok rögzítése.
IV.6 A követelmények egy lehetséges, módszertanra alapuló (SSADM) dokumentálási formája A követelmények meghatározásánál, illetve a rendszer dokumentálásánál olyan részletes dokumentumok elkészítése az igény, amely a rendszer működésének teljes megértését a fejlesztésben részt nem vevő szakemberek részére is lehetővé teszi. A dokumentálás elvárt jellegének érzékeltetésére ez a pont vázlatosan ismerteti a
51
követelmény meghatározás egy lehetséges formáját az SSADM módszertanra alapulva. Az ajánlatokban vagy egyértelműen vállalni kell az SSADM megközelítés szerinti dokumentálást, vagy az itt ismertetettekkel azonos struktúrában kell meg adni azt, hogy milyen módon biztosítja a teljes körű dokumentáltságot a fejlesztő. Ebben az esetben az átadandó dokumentumoknak nem formailag, hanem tartalmilag kell megfelelnie a módszernek, az informatikai szakmában elfogadott szakmai gyakorlattal és az érvényben lévő szabványokkal összhangban. ISO 9000-3, ISO 9126, ISO 6xxx. IV.6.1 Követelményelemzés Termék célja Összefogni a jelenlegi (ha nincs, akkor a kívánt) rendszer és a javasolt működési megoldás részleteit. Ez a követelmény-elemzési modul végterméke. Tartalom Jelenlegi szolgáltatások leírása Felhasználójegyzék Követelményjegyzék Választott rendszerszervezési alternatíva IV.6.2 Követelményspecifikáció Termék célja Meghatározni a felhasználói követelményeket, beleértve ebbe az összes korlátot és jövőbeli kiterjesztést is, oly módon, hogy lehetővé váljék a megoldási változatok kidolgozása. Ez a követelmény-specifikációs modul végterméke. Tartalom Adatjegyzék, logikai adatmodell Részletes feldolgozási specifikáció Követelményjegyzék IV.6.3 Feldolgozások részletes leírása Termék célja A feldolgozási folyamatokra vonatkozó követelmények részletes specifikálása, a lehetséges megoldások azonosítása végett.
52
Tartalom Felhasználói szerepkör-funkció mátrix Funkciójegyzék Esemény és lekérdezés jegyzék Egyedhasználati mátrix Igényelt rendszer logikai adatmodellje Entitás (Egyed)-élettörténetek Eseményhatás-ábrák IV.6.4 Adatfolyam-modell Termék célja A rendszerbeli információáramlás teljes áttekintése. E dokumentum a rendszer életciklusában a jelenlegi fizikai, a jelenlegi logikai és az igényelt szolgáltatások leírásakor kerül átdolgozásra. IV.6.5 Logikai adatmodell Termék célja Az adatokról és szerkezetükről részletes logikai leírást adni. Tartalom Logikai adatszerkezet: Egyed (egyed neve, egyed azonosítója, egyedmegjelenés / főtípus / altípus neve, stb.) IV.6.6 Egyed-élettörténetek Termék célja A termék célja az igényelt rendszer logikai adatmodelljében szereplő minden egyes egyed rendszerbeli életének ábrázolása, a születésétől a megszűnéséig, az őt érintő események felhasználásával. Modellezi azokat az adatok aktualizálására vonatkozó szervezeti szabályokat, amelyeket az új rendszernek tudnia kell. Azonosítja azokat az eseményeket, amelyeket más SSADM termékek vizsgálatával nem sikerült azonosítani és meghatározza az események megfelelő kezelése miatt esetleg szükséges változtatásokat a logikai adatmodellben. Minden egyedhez tartozik egy egyedtörténeti ábra, ezeknek a készlete nyújtja a fent meghatározott információkat az egyedekről. IV.6.7 Eseményhatás-ábrák Termék célja A termék minden eseményre bemutatja, hogy az adott esemény által kiváltott hatások milyen módon kapcsolódnak egymáshoz, illetve milyen útvonalat kell bejárni a logikai adatmodellben a hatások feldolgozásához. Minden egyes eseményt egy ábrával jellemzünk. Egy felettes esemény eseményhatás-ábrája meghívható több másik esemény ábráiból.
53
IV.6.8 Lekérdezési út Termék célja A termék célja, hogy olyan szerkezeteket alakítson ki a lekérdező folyamatokra, amelyek az igényelt rendszer logikai adatmodelljének szükséges bejárásán alapulnak. Emellett a termék elkészítése során az igényelt rendszer logikai adatmodelljének érvényességéről is meg lehet bizonyosodni azáltal, hogy ellenőrzik a szükséges adatok rendelkezésre állását és szerkezetük megfelelőségét. Minden egyes lekérdezést egy-egy ábra ír le. Egy közhasznú lekérdezés lekérdezési útját több másik lekérdezés út is meghívhatja. IV.7
Specifikáció - Rendszerfelület-terv
IV.7.1 Adatfolyam-modell [igényelt] Termék célja A választott rendszerszervezési alternatívának megfelelően és a jelenlegi rendszer logikai adatfolyam-modelljéből kiindulva megfogalmazott igényelt rendszer információáramlásainak leírása. Ennek alapján lehet majd meghatározni a rendszer funkciót illetve eseményeit. IV.7.2 Dialógusok Termék célja A dialógusokra vonatkozó összes dokumentum egy készletbe gyűjtése annak biztosítására, hogy a módszertan lépései között teljes leírást adjunk tovább. Egy-egy dialógus egy adott párbeszéd elemeit írja le és az egymáshoz illeszkedésük módját. Az egyes elemek tartalmáról részletesebb leírást is ad. A dialógusvezérlő táblázatban a dialóguselemek csoportjainak különböző érvényes bejárásait lehet megadni. A dialógusszintű tájékoztatás (help) a dialógus egészéről ad segítségnyújtás jellegű tájékoztatást. IV.7.3 Felhasználói szerepkörök Termék célja A rendszerbeli felhasználói szerepkörök teljes készletbe történő csoportosítása. Ahol ugyanazon munka / tevékenység / feladat több munkakörben (felhasználói feladatban) is szerepel, ott az összevonható egyetlen szerepkörbe. Hasonlóan járhatunk el a nagyon hasonló, de nem teljesen azonos munkakörök esetében is. Végső soron a felhasználói szerepkörök a rendszer szempontjából hasonló munkaköri részfeladatok csoportjait jelentik. Egy adott munkakörbe tartozó személy több szerepkört is betölthet, ha a munkakörébe több különböző olyan feladat tartozik, amelyet külön szerepkörbe csoportosítottak a rendszerben. A fordított eset is igaz, azaz egy szerepkört több különböző munkakörben alkalmazott személy is betölthet, ha az adott
54
munkakörökbe tartozó feladatoknak van közös része, és ez a közös rész egy szerepkörbe lett csoportosítva. Tartalom Minden szerepkörről rögzítendő: Szerepkör neve/azonosítója Munka részletei, az alábbiak ismétlődő csoportja munkakör megnevezése munkatevékenységek IV.7.4 Felhasználójegyzék Termék célja Az igényelt rendszer összes közvetlen (on-line) felhasználójának és a rájuk rótt feladatok listájának összeállítása. Ezt majd bemenetként használjuk a szerepkörök kialakításánál. Tartalom Minden egyes bejegyzés az alábbiakból áll: munkakör megnevezése munkaköri tevékenységek/feladatok leírása IV.7.5 Funkciómeghatározások Termék célja A funkciókra vonatkozó összes dokumentum egy készletbe gyűjtése annak biztosítására, hogy a módszertan lépései között teljes leírást adjunk tovább. A módszertan előző változatában ezt a gyűjtőterméket felhasználójegyzéknek hívták. Az egyes funkciók leírása meghatározza az igényelt rendszer egy-egy funkcióját. Ez a leírás összerendezi azokat az SSADM-beli dokumentációs elemeket, amelyek a funkció egyes komponenseit részletesen leírják. Ez az összerendezés a felhasználók szemszögéből írja le a rendszer feldolgozásait, amit a feldolgozások későbbi tervezésénél lehet majd felhasználni. IV.7.6 Menüszerkezetek Termék célja A termék a felhasználói szerepekre szabott, dialógusok közötti bejárható útvonalak ábrázolására szolgál, amit egy menühierarchia fejez ki. Termék tartalma Egy olyan fa-struktúra, amely a menük és dialógusok kapcsolatát mutatja. Alkalmazhatóság Azokban a projektekben, ahol van logikai terv és a felhasználói felület menüvezérelt, alkalmazható.
55
IV.7.7 Parancsszerkezet Termék célja A termék meghatározza, hogy egy adott dialógus végeztével mely dialógusokhoz illetve menükhöz lehet továbblépni. Termék tartalma Azonosító rész: Dialógus neve Felhasználói szerepkör Ismétlődő csoport: A következő választható lépés neve A következő lépés minek a része: dialógusnak vagy menünek. Dialógus/menü neve, amelyre tovább lehet lépni. Alkalmazhatóság Azokban a projektekben, ahol van logikai terv és a felhasználói felület menüvezérelt, alkalmazható.
IV.8
Specifikáció - Belső terv
IV.9
Fizikai adatterv
Termék célja A cél egy egyedi fejlesztés esetén a megvalósítástól függő adatterv létrehozása, amely biztosítja, hogy a rendszer eléri a tárolási kapacitásra és szolgáltatási színvonalra vonatkozó teljesítmény-célkitűzéseket. A termékfüggő fizikai adatterven alapuló teljesítmény kiértékelésre kerül és a tervet szükség esetén módosítják annak érdekében, hogy a felhasználók által kitűzött célokat elérjék. Termék tartalma Fizikai adatterv (kezdeti) Fizikai adatterv (optimalizált) Tárigény-becslési formalap (az adott adatbázis-kezelő jellemzőihez igazítva) Időigény-becslési formalap (az adott adatbázis-kezelő jellemzőihez igazítva) IV.10 Döntési struktúra
56
Rendszerszervezési alternatíva [kiválasztott] Termék célja A választott rendszerszervezési alternatíva leírása olymódon, hogy annak alapján majd elő lehessen állítani a követelményspecifikációt. Több lehetséges megoldást is kiértékeltek, melyek közül egy optimálist kell választani (vagy több megoldási mód kombinációját). Tartalom A választott rendszerszervezési alternatíva lényegében szöveges dokumentum, melyet ki lehet egészíteni adatfolyam-ábrákkal és logikai adatmodellel. A részletes dokumentációnak tartalmaznia kell az alábbiakat: a működés (rendszer) határai működési szintek (az egész alkalmazásra, illetve a részekre vonatkozóan) megfelelőség mértéke egyéb technikai jellegű megfontolások, mint például működtetési korlátok költség/haszon elemzés hatáselemzés a választás okainak, illetve a többi lehetőség elutasításának részletes indoklása. IV.10.1 Felhasználói szervezet Ide tartozik a munkafolyamat-modell (vagy más néven: munkaszervezési modell). IV.11 Munkafolyamat-ábrázolás funkcionális sajátosságai Munkafolyamat ábrázolás funkcionális sajátosságai Szereplők (aktorok) • A leendő rendszer informatizálásra megcélzott területének szereplői, mind az embereket mind a számítógép rendszereket ideértjük. Helyszín / telephely • Azoknak a helyszíneknek, telephelyeknek kimerítő felsorolása, ahol az aktorok, a leendő rendszer szereplői dolgoznak. Szervezeti felépítés • A leendő rendszer aktorjai közötti szervezeti, hierarchikus viszonyokat ábrázolja. Ebbe bele tartozik / struktúra az is, hogy az aktorokat szervezeti egységekbe foglalják (magukat a szervezeti egységeket is tekinthetjük aktoroknak). Információ-elérési • Az egyes aktorok információ-igénye és az igények kielégítéséhez szükséges jogosultságok leírása; ez igények és jogok valójában a rendszer külső felületéről mint információ-forrásról az aktorok, leendő felhasználók által alkotott elképzelés, nézőpont leírását jelenti. Feladatok • Az információrendszeren belül a feladatok és azok céljainak a meghatározása. Minden egyes feladatra pedig A feladat szabályai • A feladat végrehajtását meghatározó szabályok és eljárások megfogalmazása Informatizálás • A feladat végrehajtásának lehetséges módjai: manuális, számítógép által végzett vagy interaktív. Egy szintje interaktív feladatot részben a számítógép, részben a leendő felhasználó fog végrehajtani. A számítógépesítettség, az informatizáltság szintjét a feladatok részek leírásán belül kell megadni. Feladatok részekre • A feladatok részfeladatokra bontását jelenti. A részfeladatokat ugyanúgy kell kezelni mint a bontása feladatokat és ugyanúgy is kell dokumentálni. A részfeladatok esetleg még finomabb részekre bomolhatnak. • Egy interaktív feladatot manuális és számítógép által végzett részekre lehet bontani. A számítógépes részt itt nem kell tovább részletezni (ez majd a számítógép funkcionális nézetének lesz a része). A felhasznált és az • Az elektronikus és a nem-elektronikus információk leírása, amelyeket az adott feladat felhasznál előállított illetve előállít. információ Dinamikus • A feladatok illetve a részfeladatok végrehajtása során figyelembe veendő dinamikus függőségek, összefüggések ezek feltételei; nevezetesen a sorrendiség, az alternatívák, ismétlődések, párhuzamosságok, szinkronizálás, információk közötti összefüggések. Szervezeti szintű • Azoknak az eseményeknek és eredetüknek a leírása, amely az adott feladat végrehajtását okozza, események kezdeményezi. bekövetkezése révén kezdeményezett A kiváltott • Azok az események, amelyeket a feladat a végrehajtása során kivált, okoz, kezdeményez, valamint a szervezeti kiváltott esemény címzettjének az azonosítása. események A feladat • A feladat elindítása előfeltételeinek a leírása, pontos meghatározása. indításának
57
Munkafolyamat ábrázolás funkcionális sajátosságai feltételei Feladat végrehajtója • Annak az aktornak a megnevezése, aki az adott feladatot elvégzi. Vezető • Annak a szervezeti vezetőnek a megnevezése, akinek felelőssége a feladat pontos végrehajtásának ellenőrzése. Erőforrások • A feladat elvégzéséhez szükséges erőforrások megnevezése Az ember-gép • Azoknak az információknak a meghatározása, amelyek az ember-gép kapcsolatot megtestesítő kapcsolat statikus rendszerfelületen áthaladnak (ebbe beletartozik a képernyők formájának, tervének leírása, a papíron oldala megjelenő jelentések, beszámolók megjelenítése, stb.), továbbá azoknak a szervezeti szintű eseményeknek a felismerése, amelyeket egy manuálisan végzett feladat vált ki, és ezek az események számítógéppel végrehajtandó feladatot kezdeményeznek, illetve megfordítva, olyan eseményeket, amelyeket egy számítógéppel végrehajtott feladat vált ki, és ezek az emberi szereplők által elvégzendő manuális feladathoz vezetnek. Az ember-gép • A ember-gép kapcsolatot reprezentáló rendszer külső-felületen kiváltandó hatások előfeltételeinek rendszerfelület megfogalmazása. A dinamikus, rendszer külső felület viselkedést befolyásolja a számítógépes és viselkedése manuális feladatok közti dinamikus függőség is.
IV.12 Számítógéprendszer adat-ábrázolásának funkcionális sajátosságai Számítógéprendszer adat-ábrázolásának funkcionális sajátosságai Tárolt adatok • Azok a számítógépben elektronikusan tárolt adatok, amelyek azokat az információkat képviselik, melyekről úgy döntöttek, hogy számítógépesíteni fogják, továbbá a számítógépesített rendszer működéséhez szükséges adatok. Az adatok • Az adatok egyedi előfordulásainak lehetséges értékei. értékkészlete Statikus (állandó) • Az adatok közötti állandóan tekinthető összefüggéseké: függőségek
•
•
Adatok életciklusa
•
az adatok közti kapcsolatok, viszonyok mint például a kapcsolatok vajon binárisak-e, vagy többszörös kapcsolatok megengedettek-e, az adatok között fennáll-e aggregáció (bizonyos adatok összessége), vagy generalizáció (absztrakció, általánosítás). a kapcsolatokra vonatkozó korlátok, feltételek, mint például egyenlőség, kizáró VAGY, tartalmazás, számosság, funkcionális függőségek.
Az adatok egyedi példányain előforduló változtatások leírása, amelyek az adatokat a keletkezésüktől a megszűnésükig érinthetik. Ide tartozik a változtatásokat kiváltó események leírása, a változások közötti dinamikus összefüggések megfogalmazása (pl. a sorrendiség, alternatívák, ismétlődések), valamint ezen változások által okozott események érzékeltetése.
IV.13 Számítógéprendszer funkció-ábrázolásának funkcionális sajátosságai Számítógéprendszer funkció-ábrázolásának funkcionális sajátosságai Funkciók • A számítógép rendszer funkcióinak és azok céljainak leírása. Mindegyik funkcióra Bemenetek • Azoknak az üzeneteknek, információknak, adatoknak a leírása, amelyek kiváltják a funkció elindítását továbbá az eredetüknek a megnevezése. A funkció • Azoknak a feltételeknek a megfogalmazása, amelyeknek a funkció elindítása előtt teljesülniük kell. indításának előfeltételei Kimenetek • A funkció által előállított üzenetek leírása, valamint a célállomás megnevezése. Funkció felbontás • Ez a funkció részfunkciókra bontását dokumentálja. A részfunkciókat saját jogon funkcióként kezelhetjük és ugyanolyan módon is kell leírni őket. A részfunkciók ebből következően természetesen további részekre bomolhatnak. Dinamikus • A funkció részfunkciói közötti dinamikus kapcsolatokat írja le, például sorrendiség, alternatívák, összefüggések párhuzamosságok, ismétlődések, szinkronizálás, adatfüggőségek. Funkció végrehajtás • Azok a szabályok és eljárások, amelyek a funkció végrehajtását irányítják. szabályai Adat használat • A funkció által felhasznált tárolt valamint az aktualizált (létrehozott, törölt vagy módosított) adatok megnevezése.
IV.14 Számítógéprendszer sajátosságai
architektúra-ábrázolásának
Számítógéprendszer architektúra-ábrázolásának funkcionális sajátosságai
58
funkcionális
Számítógéprendszer architektúra-ábrázolásának funkcionális sajátosságai Végrehajtási • A számítógép rendszer végrehajtó egységeinek azonosítása, típusaik megadásával. (CPU) egységek Helyszín / telephely • Azoknak a telephelyeknek, helyszíneknek a felsorolása, ahol a fentebbi végrehajtó egységeket elhelyezik. Rendszer felépítés • A számítógéprendszer struktúráját, műszaki szerkezetét mutatja be leírva a végrehajtó egységek közötti műszaki kapcsolatokat. Adatok elosztása • Az adattároló egységek és a végrehajtó egységek egymáshoz rendelése. Funkciók elosztása • A funkcióknak és végrehajtó egységeknek az egymáshoz rendelése. A processzorok és a funkciók összekapcsolásának az eredménye az lehet, hogy a funkció további részekre bontása válhat szükségessé, a számítógép rendszer funkció-ábrázolásánál leírtaknál részletesebb dokumentálás kellhet. Külvilág felé • Más információrendszerek végrehajtó egységeihez vezető, külső kommunikációs kapcsolatok irányuló érzékeltetése. kommunikáció Belső • A számítógéprendszeren belüli egységek közötti kommunikációs kapcsolatok megadása. kommunikáció Mindegyik processzor egységre C • A hardver berendezések műszaki adatai, amelyek megtestesítik a végrehajtó egységet, azaz a processzorok típusai, memória méretek, átviteli sebességek, háttértároló kapacitás. Rendszer szoftver • Azoknak a szoftvereknek a műszaki jellemzői, amelyekre alapozva a végrehajtó egységet felépítik, leírások mint például az operációs rendszer, adatbázis-kezelő rendszer, tranzakció monitor, számítógéphálózatot működtető rendszer, fordítóprogramok, futtató rendszerek, stb. Az alkalmazási • Fizikai adatok: a választott hardver és szoftver konfiguráción az adatok tárolás megvalósításának a programok leírása leírása. • Programok: a választott hardver és szoftver konfiguráción a funkciók megvalósításának a leírása. A programokat a végrehajtó egységekre lebontva kell szétosztani, tehát például az ember-gép kapcsolat megvalósítását lokális adatfeldolgozásban valósítják meg, míg a központi végrehajtó egységeken tárolt adatok elérésének a kezelését központi adatfeldolgozásban oldják meg.
IV.15 Minőségi tulajdonságok Ezeknek további részletezése az ISO 9126 számú szabványban található meg. Hatékonyság
A rendszer vagy egy alkotórésze által nyújtott teljesítmény és a felhasznált erőforrások viszonya. A hatékonyság a rendszer idő-dimenzióban nyújtott viselkedéséhez kötődik tipikusan, nevezetesen a válaszidő, adatfeldolgozási idő, rendszer (feladat, munka) áteresztőképessége, továbbá az erőforrások felhasználásának mikéntjét jelenti, azaz a felhasznált erőforrások volumene, az igénybevétel ideje.
Funkcionalitás
A rendszer funkcionalitását a rendszer funkcióinak halmaza és a specifikált tulajdonságaik jellemzik. A funkciók azok, amelyek megfelelnek a szervezet működése olyan igényeinek, amelyeket kifejezetten közöltek illetve amelyek következtek vagy levezethetőek voltak az előbbiekből. További idevágó jellemzők: • alkalmasság • pontosság, szabatosság • együttműködési képesség • igényekhez való illeszkedés; • biztonság; • nyomon követhetőség;
Biztonság
A rendszer azon képessége, hogy megakadályozza az adatokhoz és a programokhoz való jogosulatlan hozzáféréseket, akár szándékos legyen akár véletlen. A rendszer azon képessége, hogy egy bizonyos idő intervallumra vonatkozóan a rendszer folyamatosan tudja szolgáltatni az előírt teljesítményt a meghatározott feltételek mellett. A meghibásodások között eltelt átlagos idővel szokták mérni. További idevágó jellemzők: • a rendszer hiba tűrő képessége • visszaállíthatóság; • rendelkezésre állás; • szolgáltatás csökkentésre való készség, • a rendszer kérleltsége.
Megbízhatóság
Karbantarthatóság
A rendszer egészének vagy egyes részeinek módosításához szükséges erőfeszítések nagysága jellemzi. A rendszer módosítások közé értendők a hiba javítás jellegű, korrekciós karbantartások, a tovább fejlesztés vagy a környezet változása miatti adaptációs fejlesztés, továbbá a követelmény és funkcionális specifikációban végzendő javítások. További idevágó jellemzők: • elemezhetőség egyszerűsége; • változtathatóság, módosíthatóság mértéke;
59
• • • •
a rendszer stabilitása; tesztelhetősége; kézben tarthatósága (üzemeltetés, működés közben); újra felhasználhatósága.
Hordozhatóság
A rendszer azon sajátossága, hogy milyen könnyen lehet a rendszer egészét vagy bizonyos részeit egy teljesen más környezetbe (technológiai és szervezeti értelemben is) átültetni. További idevágó jellemzők: • adaptációs képesség; • üzembe-helyezés egyszerűsége; • kicserélhetősége, helyettesíthetősége; •
Használhatóság
A leendő felhasználóknak, a rendszer aktorainak, mekkora nehézséget okoz a rendszer használata, mennyire egyszerű, könnyű a rendszerrel dolgozni. További idevágó jellemzők: • megérthetőség; • megtanulhatóság; • üzemeltethetőség, működtetés egyszerűsége; • a rendszer működésének átláthatósága, nyíltsága; • testre-szabhatósága; • megjelenésének vonzereje; • a működés világossága; • segítség és támogatás nyújtási szolgáltatásainak színvonala; • felhasználó-barát-e.
IV.16 Beruházás jellemzői Költségek Nyerhető hasznok, előnyök Kockázatok
A rendszer kivitelezésének, karbantartásának, üzemeltetésének költségei, illetve egyes egyedi alkotóelemeié. Azoknak az előnyöknek a felsorolása, amelyeket az adott alkotórész eredményez vagy nyújt a rendszer egészére vagy egy meghatározott komponensére, amely ezt az alkotórészt magában foglalja, illetve azoknak a hasznoknak a kimutatása, amelyek a szervezet működésének egészére származhatnak. Azoknak a kockázatoknak az érzékeltetése, amelyek a rendszer egészének illetve bizonyos részeinek kivitelezése, karbantartása és üzemeltetése során felmerülhetnek.
60
V. A szerződéses alkalmazás fejlesztés során szükséges mértékek (metrikák), informatikai mennyiségek Az alkalmazási rendszerek teljes életciklusa során különböző mennyiségek gyűjthetők és elemezhetők. Ezek a metrikák különböző diagrammokon ábrázolhatók és a vezetés számára megjeleníthetők. Akár belső fejlesztésnél, akár vállalkozási szerződés keretében végzett fejlesztésnél, akár szolgáltatás kihelyezésnél ezeknek az informatikai mennyiségeknek nagy jelentősége van a fejlesztés előrehaladásának mérésében, a költség ráfordítások realitásának megítélésében, a rendszer megbízhatóságának és minőségének értékelésében. A következő pontokban felsoroljuk azokat a jellemző mennyiségeket és metrikákat, amelyek ésszerű erőfeszítések árán képet adnak a fejlesztés alatti rendszerről számszerűsíthető és vezetői szinten értékelhető formában. Ezek a mennyiségek és mérőszámok a rendszer és a rendszerfejlesztésről összevont, aggregált és sűrített formában közölnek információkat. Természetesen a felsorolás nem teljes körű, az egyedi helyzetek sokfélesége miatt a mérések teljesen nem tipizálhatók. V.1
Primitív, vagy egyszerű metrikák
V.1.1 Problémák mérése a) Fejlesztési szakaszonként a probléma jelentések száma, fontossága, kategóriája és/vagy oka; b) A jelentett problémák száma egységnyi időre vetítve; c) A még meg nem oldott, nyitott problémák száma egységnyi időre vetítve; d) A lezárt problémák száma egységnyi időre vetítve; e) A ki nem értékelt problémák száma; f) Mennyi ideig maradnak a problémák nyitott állapotban; g) Mennyi ideig maradnak a problémák kiértékeletlen állapotban; h) Mennyi ideig tart, amíg egy problémát lezárnak, megoldanak; i) Hiba bejelentések ideje; j) A hiba bejelentések gyakorisága. V.1.2 Változtatási metrikák a) A változtatások, hozzáillesztések, törlések, vagy módosítások száma; b) A követelmény specifikáció és /vagy a rendszerterv megváltoztatására benyújtott kérések száma a szoftver életciklusa alatt a követelmény elemzési szakasz után. V.1.3 Hiba mértékek A hibák kiküszöbölésére tett erőfeszítések hatékonyságának és eredményességének mérésére és annak ellenőrzésére, hogy vajon elegendő ráfordítás történt, történik a hibák megszüntetése érdekében. a) A fejlesztési szakasz végén a ki nem küszöbölt hibák száma; b) Azoknak a hibáknak a száma, amelyeket teljesen behatároltak, még sem javították ki, továbbá még az elintézetlen változtatási kérelmek száma c) A minőségi szemlék és kód felülvizsgálat (walkthroughs) során feltárt követelmény specifikációs és tervezési hibák.
61
V.1.4 Követelményelemzés, -specifikáció metrikái V.1.5 Egyszerű rendszer méret metrikák Ezek egyszerű leszámolást jelentenek. A józan-észből és a tapasztalatokból kiinduló feltevések arra támaszkodnak, hogy a nagyobb egységekben a hibák előfordulási gyakorisága nagyobb, és sokkal nehezebb a működésüket megérteni; ennek megfelelően változik a megbízhatóságuk és bővíthetőségek. a) Az oldalak vagy szavak száma; b) A követelmények száma; c) A funkciók száma. V.1.6 Funkció pont metrikák Ezek a metrikák, informatikai mennyiségek mérése az elmúlt évtizedekben jelentős fejlődést mutattak. A kutató laboratóriumok falai közül kikerülve a szoftver ipar alkalmazási rendszert gyártó ágazatának normatív rendszere felé fejlődnek. Ma már piacon kapható publikációk tartalmazzák az ipari normának tekinthető funkció pont táblázatokat, grafikonokat. Sőt ezen túl menően az első költségtervezési publikációk is megjelentek, amelyek a funkció pont normákhoz az iparban elfogadott munkaóra és költségtényezőket rendelik. A szolgáltatás kihelyezésnél, hagyományos vagy nem hagyományos fejlesztési és partnerségi szerződéseknél akkor, amikor alkalmazás fejlesztésről, karbantartásról továbbfejlesztésről van szó jelentős sikereket könyvelhet el ez a megközelítés. Két nagy iskola van, a gyakorlatban azonban bármelyik megközelítés jól használható, ráadásul a két módszer által adott értékek jó közelítéssel átszámolhatók egymásba. a) ’IFPUG’ Funció pont (International Function Point Users Group, Nemzetközi Funkció Pont Felhasználói Csoport) b) ’MkII’ Funkció pont A funkció pont megközelítés lényege, hogy csak azokat a funkciókat veszi figyelembe, amelyek valóban szolgáltatásokat nyújtanak a felhasználó számára. Az adat-intenzív, adatbázisra alapuló alkalmazásoknál figyelembe veszi a funkciók be- illetve kimenő adatait (különböző súlyozással), valamint az érintett adatbázis elemeket (entitásokat, relációkat, táblázatokat, adatállományokat, stb.).Az így kapott értéket egy rendszer bonyolultsági, technológiai bonyolultsági tényezővel megszorozva kapják a funkció pont értéket. V.1.7 Követelmények nyomon követhetősége Ez a mennyiség azt méri, hogy követelmények hányad része valósult meg a tervben, valamint a hiányzó követelmények és az esetleges bővülés jelzésére is használható. RT= R1/R2×100%, ahol R1 a megvalósított követelményeket, az R2 pedig az eredeti követelmények számát jelenti.
62
V.1.8 Teljesség A szoftver specifikáció teljességének meghatározására szolgál. Ez a metrika 18 egyszerűbb informatikai mennyiséget használ: − a nem kielégítő módon meghatározott funkciók számát, − a funkciók számát, − a meghatározott de nem használt funkciók számát, − a hivatkozott funkciók számát, − a döntési pontok számát − stb. Ezekből származtatott mennyiségeket vezetnek le (10 darabot).Ezeket az értékeket 0 és 1 közé eső tényezőkkel súlyozva összegzik, a súlyok összege 1 és az összegzés a 10 származtatott mennyiségre fut. V.1.9 Meghibásodási napok száma Ez azt az értéket méri, hogy a hiba keletkezése és eltávolítása között hány nap telt el. Ez két egyszerűbb informatikai mennyiséget használ: annak a szakasznak, napnak, időszaknak az azonosítóját, amikor a hiba létrejött illetve, amikor kiküszöbölték. A meghibásodási napok száma a keletkezéstől a megszüntetésig tartó napok száma, a mennyiséget ezeknek az értékeknek a felösszegzésével nyerik. V.1.10 Bevizsgálási, tesztelési metrikák V.1.11 Hiba számok Az egyes program modulokban feltárt hibák száma; − a rendszer eleme és az integráció teszt során feltárt követelményelemzési, tervezési és programozási hibák száma; − a hibák száma típusonként (e.g. logikai hiba, számítási hiba, kapcsoló felület hibája, dokumentációs hiba) − a hibák száma ok vagy eredet szerint; − a hibák száma súlyosság szerint (működést kritikusan befolyásoló hibák, lényeges, jelentősebb hibák, kozmetikai hibák). Egyéb mennyiségek : − hiba sűrűség − a hiba élettartama; − a hiba jelzésre való reagálás reakció ideje; − a hiba javítás költsége; − A hiba javítás hatékonysága. V.1.12 Változtatások mértékei (üzemeltetés, karbantartás) Egyszerű változtatást mérő mennyiségek: − A változtatások száma; − a változtatások költsége, ráfordítása; − az egyes változtatások idő igénye; − A hozzáadott, törölt, módosított program sorok száma; − A kijavított hibák száma, illetve a bővítések száma. Felhasználók elégedettsége: közvélemény kutatással meghatározható, a szállító termékeinek illetve kapcsolódó szolgáltatásainak értékelés 1 –től 10-ig terjedő skálán.
63
V.1.13 A lopakodó felhasználói követelmények kezelése A szoftver projektek 90 %-ban a követelmények a fejlesztés során megváltoznak, ezért a lopakodó felhasználói követelmények a szoftver ipar egyik legnagyobb gondját jelentik. Különböző eljárásokat fejlesztettek ki ennek a problémának a kezelésére. Az egyik lehetséges szerződéses kezelés a következő: V.1.14 Mozgó költség skála az egységnyi funkciópont árára A USA szoftver ipari átlagokra támaszkodó minta táblázat: Kezdetben 1000 funkciópont a rendszer 500 US $/ FP mérete A szerződés aláírása után 3 hónappal 600 US $/ FP hozzáadandó új igényekre A szerződés aláírása után 6 hónappal 700 US $/ FP hozzáadandó új igényekre A szerződés aláírása után 9 hónappal 900 US $ / FP hozzáadandó új igényekre A szerződés aláírása után 12 hónappal 1200 US $ / FP hozzáadandó új igényekre Felhasználói kérésre törölt vagy 150 US $ / FP elhalasztott felhasználói követelmények Funkciópont ára fejlesztési szakaszonként (példa US$-ban) Fejlesztési és karbantartási szerződéseknél a funkciópont metrika használatának előnye abban áll, hogy a felhasználói követelményekre alapul és nem lehet a szerződő partner részéről egyoldalúan módosítani: hozzátenni vagy elvenni belőlük. Ellentétben például a programsorok számára vonatkozó megállapodásokkal.
64
VI. Az egyes funkciók informatikai megfelelőségének vizsgálatához használható szempontok Az adatbevitel (input) Az adatfeldolgozás Kimenet teljessége és pontossága teljessége és ellenőrzése pontossága
(output) Jogosultságok (Authorization)
Győződjön meg arról, hogy a Győződjön meg arról, hogy Győződjön meg arról, hogy a Győződjön meg arról, hogy tranzakció teljesíti a következő a tranzakció teljesíti a kimenet: valamennyi a rendszerbe kritériumokat: következő kritériumokat: került és használt adat a feldolgozás során:
Az adatot bevitték a számítógépbe és a rendszer azt elfogadta Az adatot csak egyszer továbbították feldolgozásra Nem történt többszörös adatbevitel és
a rendszer elfogadta a tranzakciót a feldolgozás érvényes logikát követ az adatfeldolgozás valamennyi fázisa befejeződött
A pénzügyi és nem pénzügyi a módosítások során adatmezőkben előforduló hibá (a helyes adatmezők program hibakezelése észleli, és véglegesek megfelelő hibaüzenetet küld)k: 1.) azonosítva vannak 2.) el lettek különítve az érvényes tranzakcióktól 3.) időrendi sorrendben lettek kijavítva 4.) Az ellenőrzésnek következőkre kiterjednie:
Felhasználásával megfelelő módon történt a jelentések, beszámolók előállítása Csak arra feljogosított személyek számára látható, illetve hozzáférhető Megsemmisítése és a megőrzése megfelel a szabályoknak
Biztonság
Üzemeltetés
Győződjön meg arról, hogy az eszközökhöz, szolgáltatásokhoz, információkhoz való hozzáférés azokra az egyénekre van korlátozva, akiket a menedzsment erre felhatalmazott.
Győződjön meg arról, hogy a tárolt adatok aktuálisak, naprakészek, a kivételes, szokatlan adatok kezelése megoldott.
A menedzsment által jóváhagyott és Jellemző az aktuális eseményre
a A szükséges audit (pénzügyi a ellenőrzési, revizori) eljárásoknak megfelel Ha hibás, el van különítve az érvényes tranzakcióktól, kijavítása megtörtént és a javított kimenet a feldolgozás szerves része lesz a kell
Az adatbevitelre vonatkozó
65
Az ellenőrzésnek a következőkre kell kiterjednie: Kézzel aláírt felhatalmazás
Az
ellenőrzésnek
a Az
ellenőrzésnek
a
Az adatbevitel (input) Az adatfeldolgozás Kimenet teljessége és pontossága teljessége és ellenőrzése pontossága
(output) Jogosultságok (Authorization)
ellenőrzéssel kapcsolatosan, hogy az ellenőrzés a feldolgozás megfelelő fázisában történik-e
Biztonság
Üzemeltetés
Elektronikus felhatalmazás következőkre kell kiterjednie: Mező szintű ellenőrzések, programozott eljárások Bejelentkezés/jelszó szabályozása A fizikai hozzáférés szabályozása A jelentések szétosztása A printerek biztonságos tárolása
Az ellenőrzésnek a következőkre Program rész futtatások kell kiterjednie: közötti Ellenőrzési összegek (Run to run control totals) Ellenőrzési (rész)összegek mező szintű adatbeviteli (bizonylatok napi, heti, ellenőrzés havi),(control totals) programozott eljárások 1 az 1-hez ellenőrzés párhuzamos, megismételt (bizonylatok és a bevitt feldolgozás adatrögzítés elektronikus adatok egyeztetése) illesztés (matching), adat az kivételek jelentése adatbázisban tárolt értékkel egyezik (cég azonosító, stb.) sorrendre vonatkozó ellenőrzés (szigorúan számozott bizonylatok)
Az ellenőrzésnek a következőkre kell kiterjednie:
előzetesen rögzített, (bizonylatra
A
Szigorúan Sorszámozott bizonylatok A jelentések szétosztása A több helyről származó adatokkal történő egyeztetés A pillanatnyilag érvényes kimeneti adatok egyeztetés?? Rekord és adatállomány megőrzés, tárolás A különösen bizalmas, valamint a lényegtelen adatok megsemmisítése Rendszerhasználat és adatfeldolgozás naplózása A különösen bizalmas kimeneti dokumentumok és formátumok biztonságos és bizalmas, vagy titkos kezelése
66
hibás
formátumok
A
forrás
dokumentumok,
következőkre kiterjednie:
kell
Összegek ()(napi, heti, havi,éves) Kivételek jelentése(Az előírttól, vagy a rendszer által befogadható adatoktól való eltérés) 1 az 1-hez egyeztetés (bizonylat – rögzített adat) A program biztonsága
Az adatbevitel (input) Az adatfeldolgozás Kimenet teljessége és pontossága teljessége és ellenőrzése pontossága kinyomtatott) inputok párhuzamos, megismételt adatrögzítés mező szintű adatbeviteli ellenőrzés: Ésszerűség Függőség (adatbázis, logikai) Érték Tartomány Létezés Formátum Ellenőrző számhegy Elsődleges adatillesztés??
(output) Jogosultságok (Authorization)
elkülönítése az érvényes adatoktól A még fenááló hibás adatok javítása és a javított adatok újra feldolgozása A javított adatok érvényesítése
67
Biztonság speciális formátumú dokumentumok biztonságos tárolása, szükség esetén titkosítása Újraindítási/helyreállítási eljárások
Üzemeltetés
Felhasználói dokumentáció
Folyamatos üzemvitel fenntartása
Az ellenőrzések időzítése
Az információ minősége, hatékonysága, hasznossága
A felhasználói dokumentáció az alkalmazás A felhasználói folyamatos üzemvitel fenntartása két részre Az az időtartam, amelyet a kontrolok Ahhoz, hogy a tranzakció során napi felhasználói számára az információ osztható. igényelnek, lényegesen befolyásolja létrejött információ hasznos legyen elsődleges forrása. hatékonyságukat. a felhasználó számára, többlet értékeket kell nyújtania, a kiindulási Újraindítási/helyreállítási eljárások Ha a bemeneti adatokhoz való hozzáférés állapothoz képest. A felhasználói dokumentáció kulcs korlátozása előtt történik a mező szintű komponensei: Néhány végfelhasználói kontrol, Azok az eljárások, amelyek a gyors helyreállítást ellenőrzés, az adat megváltoztatható. mint az illesztés (adatbázisbeli támogatják a teljes rendszer, illetve részrendszerei leállása A rendszer leírása Ha az ellenőrző összeg vagy sorszám értékhez), ellenőrző összeg, esetén. Kulcskomponensei: A rendszer struktúrájának grafikus kialakítása és a tranzakció létrehozása között szekvenciális ellenőrzés (szigorúan reprezentációja, amelynek szekvenciális A feldolgozási tevékenységek állapotának azonosítása, a hosszabb idő telik el, az adat számozott bizonylatok, elektronikus sorrendben tartalmaznia kell mind a kézzel leállás okának megállapítása céljából megváltoztatható. adatok) számítógépes megvalósítási végzett, mind az egyéb informatikai Állapotellenőrzés és a leállás során érkezett üzenetek módja hatékonyabb az egyéb tevékenységeket. Ha az egyeztetés a tranzakció végrehajtását módszereknél. kezelése A forrás dokumentációk leírása, valamint késve követi, hibák kialakulása lehetséges. felhasználásuk módja (bizonylatok) A jelentésekkel szemben támasztott Ellenőrzési eljárások beleértve a követelmények: egyszerűen megszakítással kapcsolatos követelményeket, kezelhetők, megfelelőképpen a hibajavítást, egyeztetési, illesztési részletezettek legyenek és ne feladatokat. tartalmazzanak túl sok információt.
68
Felhasználói dokumentáció
Folyamatos üzemvitel fenntartása
Az ellenőrzések időzítése
Az információ minősége, hatékonysága, hasznossága
A rendszer kimeneteinek leírása, azon eljárások leírásával együtt, amelyek a kimenet biztonságára, felhasználására, elhelyezésére, áttekinthetőségére, megőrzésére vonatkoznak Azon személyek megnevezése, akik felelősek az ellenőrzésért A hivatkozásként használt kódok, táblázatok listája
Intézkedés a tranzakciók másolatainak felhasználására, valamint az adott állomány mester kópiájának használatára az újraindításhoz A részlegesen feldolgozott tranzakciók visszaállítása
Ha a hiba meghatározása a feldolgozás korai szakaszában történik, ez csökkenti a hiba káros hatását. Így általában költség megtakarítást eredményez az on-line mező szintű ellenőrzés, a kötegelt feldolgozás csoportban végrehajtott ellenőrzésével
A menedzsmentnek a származtatott, összegzett és a kivételes eseteket tartalmazó jelentésre van szüksége ahhoz, hogy átlássa a folyamatot.
Katasztrófa/helyreállítás eljárásai Azokat az eljárásokat foglalja magába, amelyek a számítógépes feldolgozás egy hosszabb leállásához kapcsolódnak. Tipikusan ilyenek a természeti csapások, katasztrófák, illetve egyéb az alaprendszer meghibásodása által okozott problémák. Kulcs komponensei: Alternatív kézi, illetve automatizált feldolgozási eljárások a kritikus komponensekre Újraindítási/helyreállítási eljárások felhasználásának képessége
69
VII. A mennyiségi , funkcionális átvételhez használandó funkció -mátrix Szerződésbeli Követelményteljesülési követelmény hivatkozás kategória Funkciók
1.
70
A megvalósító megnevezése
felhasználói modul A funkcionális A tesztforgatókönyv tesztforgatókönyv hivatkozás hivatkozás
71
