MÓDSZERTAN LEÍRÁS. NKTH Biztonsági rendszertervezési módszertan Terjedelem: 69 oldal Készítette: Dr. Remzső Tibor

MÓDSZERTAN LEÍRÁS NKTH Biztonsági rendszertervezési módszertan

2007.09.05. Terjedelem: 69 oldal Készítette: Dr. Remzső Tibor

A dokumentum adatlapja Azonosítás

Dokumentum adatai

Dokumentum címe Dokumentum tárgya Állomány neve Dokumentum típus

Biztonsági rendszertervezési módszertan Rendszertervezési és szoftver fejlesztési módszertan biztonsagi_rendszerfejlesztesi_modszertan_1p0.doc Módszertan leírás

Dokumentum verzió

1p0

Dokumentum állapot

Végleges

Dátum

2007. szeptember 5.

Készítette

Dr. Remzső Tibor

Ellenőrizte

Papp Attila, [email protected]

A dokumentum bizalmas információkat tartalmaz! A jelen dokumentum kizárólag a NKTH részére készült. A NKTH megbízott munkatársain kívül más személy, szervezet nem használhatja fel semmilyen célból. A dokumentumot részben vagy egészben másolni, vagy bármi más módon mások számára elérhetővé tenni kizárólag a NKTH és a KÜRT Zrt. írásos engedélyével megengedett.

A dokumentum 69 számozott oldalt tartalmaz.

A dokumentumot készítette:

KÜRT Zrt. Információmenedzsment 1112 Budapest, Péterhegyi út 98. Tel.: +36 1 424 6666 • Fax: +36 1 228-5414 [email protected] • www.kurt.hu

2007.09.05. • Módszertan leírás

2/69

Tartalomjegyzék 1

Bevezetés 1.1 Rendszerfejlesztés 1.2 Hazai irányzatok, biztonság tudatos fejlesztés 2 SSADM fejlesztési eljárás 2.1 Alapok 2.1.1 Filozófia 2.1.2 Modellek: 2.1.3 Életciklus lefedése: 2.1.4 Leszállítandó termékek: 2.1.5 Előfeltételezések: 2.2 Döntési pontok 2.2.1 Az SSADM helye az információs rendszerek életciklusában 2.2.2 A módszer felépítése 2.2.3 A módszer célja 2.3 A módszer rövid áttekintése, szakaszok 2.3.1 Megvalósíthatóság-elemzési modul (FS) 2.3.2 Követelmény-elemzési modul (RA) 2.3.3 A jelenlegi helyzet vizsgálata 2.3.4 Rendszerszervezési alternatívák 2.3.5 Követelmény specifikációs modul (RS) 2.3.6 Logikai rendszerspecifikációs modul (LS) 2.3.7 Rendszertechnikai alternatívák 2.3.8 Logikai rendszertervezés 2.3.9 Fizikai rendszertervezési modul (PS) SSADM és információbiztonság 2.4 2.4.1 SSADM követelmény-elemzés és információbiztonság 3 Microsoft Solution Framework 3.1 Alapok 3.2 MSF csapatmodell 3.3 MSF folyamatmodell 3.4 Egy tipikus MSF folyamat 3.4.1 MSF kockázatkezelés 3.4.2 Fejlesztési csapatmodell 4 Rational Unified Process (RUP) 4.1 A fejlesztés folyamata 4.1.1 A Unified Process jellemzői

5 5 6 9 9 10 10 10 10 10 11 11 13 14 16 16 17 17 19 19 21 22 22 23 25 27 31 31 32 34 36 37 38 39 39 42


3/69

4.1.2 Összefoglalás 5 A szoftver folyamat érettsége 5.1 Szoftverfejlesztési képesség-érettség 5.2 Érettségi modellek 5.2.1 Lépcsős modellek 5.2.2 Folytonos modellek (continuous models) 5.2.3 Kombinált modellek 5.3 A CMM érettségi szintjei 5.3.1 Kezdeti szint 5.3.2 Ismételhető szint 5.3.3 Meghatározott szint 5.3.4 Menedzselt szint 5.3.5 Optimalizált szint 5.4 A CMMI modell 5.4.1 A CMMI folyamat dimenziója 5.4.2 Egy példa CMMI folyamatra 5.5 SEI +SAFE, V1.2, A Safety Extension to CMMI-DEV, V1.2 5.5.1 A +SAFE és a CMMI-DEV kapcsolata 5.5.2 A +SAFE és más információbiztonsági szabványok 5.5.3 A két Process Area rövid leírása 6 Fogalmak jegyzéke 7 Felhasznált irodalom

46 47 47 47 47 48 48 48 49 49 50 50 50 51 51 52 54 56 56 59 61 69


4/69

1

Bevezetés

1.1 Rendszerfejlesztés A rendszerfejlesztési tevékenységek definíciója számos alapozó munkában megtalálható. A számítástechnikai eszközöket alkalmazó rendszerek kidolgozása, a kapcsolódó szoftver eszközök, és adatbázisok kidolgozása immáron sok éves múltra tekinthet vissza. A szoftverek osztályozhatók a felhasználók jellege szerint (egyedi felhasználó számára vagy felhasználók szélesebb rétegei számára készített szoftverek), valamint aszerint, hogy új programok írásával, egy általános szoftver alapul vételével és átkonfigurálásával, vagy egy létező szoftver újrafelhasználásával jöttek létre. A számítástechnikai rendszerek elkészítése napjainkban iparszerű tevékenységgé vált, amelynek technológiai megjelenése egy speciális mérnöki-gyártási tudománnyá vált, ez az ún. szoftvertechnológia. A szoftvergyártás technológiájának napjainkra jól körülírt elmélete és gyakorlata alakult ki, amelynek modelljeit számos nemzetközi szabvány rögzíti. A szoftverfolyamatok (vagyis azoknak a tevékenységeknek, módszereknek, eljárásoknak és transzformációknak az összessége, amelyeket az emberek szoftver fejlesztésének vagy karbantartásának céljából végeznek) végrehajtásával kapcsolatban az egyéb gyártási folyamatokkal kapcsolatos gondok jelentkeznek. A folyamatok lefutásának ideje, költségei, a specifikációk minősége, a kidolgozott eszközök minősége, biztonsága nem minden esetben felel meg az elvárásoknak. Felmérések alapján (Standish Group — CHAOS Study) a nagy szoftveres projekteknek 42%-a hoz létre működőképes eredményeket, a közepeseknek 65%-a, a kisebbeknek 74%-a. A probléma megoldása a folyamatjavítás, amely a tervezésifejlesztési technológia folyamatos javításával biztosítja azt, hogy a létrehozott termékek folyamatosan javuljanak. A folyamatjavítás lehetővé teszi a rendszerekben maradó hibák arányának csökkentését (az ilyen hibák javítása az alkalmazóknál számítástechnikai erőforrásaik akár 30-40%-át is igénybe vehetik időlegesen!), a projektek átfutási idejének csökkentését, a szoftverkészítés termelékenysége jelentősen megnőhet. A szoftvergyártási modellek logikailag a következő kategóriákba tartozhatnak. • Vízesés (waterfall) modell • Iteratív fejlesztési modell • Komponens alapú szoftverfejlesztés A különféle szoftvergyártási modellek egyes költségtényezői lényegesen eltérnek egymástól. A vízesés modell szerinti fejlesztésnél a specifikációs, tervezési és fejlesztési részek


5/69

költségei azonos nagyságrendbe esnek, az integrációs és tesztelési rész a folyamat legköltségesebb eleme. Az iterációs fejlesztésnél a specifikációs rész igen kicsi, az iteratív fejlesztés a legnagyobb költségű, a rendszerteszt az összköltség mintegy 40%-át teszi ki. A komponens-bázisú szoftverfejlesztési folyamatban a specifikáció költsége lényegében a vízesés modell nagyságrendjébe esik, a fejlesztés az újrafelhasználható komponensek miatt viszonylag alacsony költségű, a folyamat legköltségesebb eleme az integrációs és tesztelési fázis. A későbbi elemzések előzeteseképpen a biztonsággal kapcsolatban itt csak annyit jegyzünk meg, hogy már a specifikációs szakaszban ki kell térni a biztonság kérdéskörére, legalább a következő kérdéskörökben: • Az informatikai rendszer által kezelendő adatoknak az információvédelem és a megbízható működés szempontjából való elemzése és a védelmi célkitűzések meghatározása • Az informatikai rendszer várható biztonsági osztályba való sorolása • A jóváhagyott költségvetésben a biztonsági eljárások tervezési és megvalósítási költségeinek szerepelnie kell • Szerepelnie kell a specifikációban a későbbi informatikai biztonsági auditnak is Az egyes szoftver folyamat modelleknél bemutatjuk, hogy a fejlesztés mely szakaszaiban kell külön szerepelnie az információbiztonságnak.

1.2 Hazai irányzatok, biztonság tudatos fejlesztés A rendszer- és szoftverfejlesztés témakörét Magyarországon napjainkban kiemelten kezelik, ennek

oka

az

informatika

kiemelt

szerepe

a

gazdaságban

és

az

irányítási

tevékenységekben. A versenyképes rendszer- és szoftverfejlesztő ipar kialakítása és működtetése elengedhetetlenül fontos ahhoz, hogy a magyar vállalkozások eredményesen bekapcsolódhassanak a nemzetközi munkamegosztásba. A jelenlegi számítógépek architekturális alapjai mintegy 20 évre nyúlnak vissza hardver és operációs rendszerek tekintetében egyaránt. Akkor lényegében még nem számoltak azzal, hogy a PC eszközök nyílt hálózatra csatlakoznak majd. Ezzel együtt az is jellemző, hogy egy berendezésen futnak biztonságos és nem biztonságos programok is. A nyílt hálózatok biztonsági problémáinak kezelése utólagosan megoldandó kérdésként jelentkezik, elsősorban a követő típusú (reaktív és nem proaktív) megoldások a jellemzőek. A biztonsági problémák kezelése továbbá kilépett abból a korszakból, amikor pusztán IT technológiai kérdésként volt kezelendő, mivel az IT eszközök alkalmazása ma már


6/69

szervesen illeszkedik ügyviteli folyamatokba, és emiatt a technológiai védelem mellett az információ kezelési folyamatok védelme is elengedhetetlen. Jellemző továbbá a mai helyzetre a biztonsági megoldások költségként való felfogása is, az újabb kutatások azonban rámutatnak arra, hogy a biztonság elsősorban befektetés. A vállalatok és szervezetek többsége még ma is informatikai üzemeltetési kérdésnek tekinti az INFORMATIKA-BIZTONSÁGot és gyakran alulértékelik a kockázatokat, holott az INFORMATIKABIZTONSÁGi problémák ma már a legtöbb esetben az egész szervezet működésre közvetve

vagy közvetlenül kihatnak. Emellett sok esetben hiányoznak a biztonság-tudatos fejlesztéshez, és üzemeltetéshez a megfelelő szintű alkalmazói, felhasználó ismeretek is. A biztonság-tudatos fejlesztési, üzemeltetési módszerek fokozatos megjelenése és használatuk általánossá válása elősegíti a proaktív (és nem reaktív) védekezési módok előtérbe kerülését. Ma már számos olyan módszertan létezik, amely lehetővé teszi, hogy az eszközök, alkalmazások és rendszerek tervezése során megfelelő figyelmet fordítsanak a felmerülő biztonsági problémák kezelésére. Ilyen módszertan például a Survivable Systems Engineering, amely elősegíti, hogy a rendszerek minden esetben biztosítsák a létfontosságú szolgáltatások ellátását és a létfontosságú adatok védelmét, vagy a Survivable Systems Analysis, amely a meglévő rendszerek túlélésének biztosítását segíti elő. Hasonló jellegű, a biztonság szempontjából is előremutató kezdeményezés a Trustable Computing Platforms létrehozása is, amelynek lényege, hogy létrehozzanak egy, a rendszeren belül fizikailag is elválasztott környezetet (a saját biztonságos periféria- és rendszerhozzáférésekkel, memóriával), ahol digitális aláírás-technológia biztosítja a nem megbízható programok futásának kizárását. Az

elkövetkező

5-10

év

során

lényegében

kialakulnak

és

elterjednek

azok

a

szoftverfejlesztési módszertanok, architekturális megoldások, és üzemeltetési gyakorlatok, amelyek lehetővé teszik az informatikai eszközök és rendszerek biztonságosabb használatát. Az általános biztonsági szint növekedésére különösen nagy hatása lesz a biztonságosabb szoftverfejlesztést lehetővé tevő módszertanok megjelenésének. A biztonsági problémák többsége a szoftverfejlesztés problémáira vezethető vissza. Jelenleg nem állnak rendelkezésre olyan módszertanok és eszközök, amelyek lehetővé tennék, hogy a piac által megkövetelt gyorsaság mellett is biztosítható legyen a biztonságos szoftver fejlesztése. Fontos látni, hogy a megfelelő funkcionalitással működő szoftver még nem feltétlenül biztonságos. A minőségi szoftver fejlesztés segíti ugyan a biztonsági problémák kiküszöbölését, ugyanakkor biztonságos szoftver előállítása mindig többletköltséggel jár. A biztonságos szoftverfejlesztést lehetővé tevő módszertanok használatának általánossá válása a 2010-es évek első felére várható.


7/69

Szükség van a projekt és a támogatási környezetek szigorú ellenőrzésére. Az alkalmazói rendszerekért felelős vezetőknek vállalniuk kell a felelősséget a projekt és a támogatás környezetének biztonságáért. Gondoskodniuk kell arról, hogy megvizsgálják a rendszerben javasolt összes változtatást és megállapítsák, mennyiben befolyásolják ezek a rendszer vagy működési környezete biztonságát. Szükséges megfelelő fejlesztési szabályok kialakítása is. Mivel az informatikai eszközök és rendszerek biztonsága jelentősen függ az üzemeltetők és felhasználók felkészültségétől is, ezért az előfeltételek közé kell sorolnunk a biztonsági kockázatok csökkentését elősegítő felhasználói és üzemeltetői ismereteket kialakulását is. A biztonság-tudatos felhasználói és üzemeltetői magatartás megteremtése elsősorban oktatás kérdése. A nem megfelelő biztonságból eredő károk egy része nem ott jelentkezik, ahol az adott biztonsági kockázat keletkezik. Például egy banki rendszer nem megfelelő biztonsága elsősorban a bank ügyfeleinek okoz kárt és csak másodsorban a banknak. Ezért ilyen területeken szükséges olyan szabályozás, amely visszahárítja a kockázatból eredő kárért való felelősséget arra a félre, amely a kockázat keletkezéséért felelős. A szabályozásnak való megfelelőség igazolása és a piaci bizalom megőrzése miatt egyre fontosabbá válik a termékeknek és rendszereknek harmadik független fél által történő biztonsági vizsgálata és tanúsítása. A jelenleg létező értékelési és tanúsítási tevékenység stabilizálódása, az értékelési és tanúsítási rendszerek konszolidációja ezért elengedhetetlen feltétele a biztonságos fejlesztés és üzemeltetés kialakulásának. A jelen anyagban áttekintjük a legfontosabb használatos rendszerfejlesztési módszertanokat és szoftvertechnológiai megoldásokat, amelyek alapul szolgálhatnak a biztonság-tudatos fejlesztési tevékenységeknek. A jelen projektben használt rendszerfejlesztési módszertan használja az alább felsorolt rendszerfejlesztési módszertanok legfontosabb elemeit, mérőszámit, dokumentumait, de leginkább a Microsoft által kifejlesztett MSF módszertanra épít. A fejlesztési módszertanunk épít a szoftver folyamatfejlesztés legfontosabb nemzetközi eredményeire is, különösen a CMM modell szerinti eljárásokra.


8/69

2

SSADM fejlesztési eljárás

2.1 Alapok Az SSADM (Structured Systems Analysis and Design Method) tulajdonosa a CCTA (Central Computer

and

Telecommunications

Agency),

amely

Nagy-Britannia

pénzügyminisztériumához tartozik, és a kormányzati információs rendszerek beszerzése és készítése felett lát el felügyeletet, valamint az információs rendszerek és az informatika területén a kormányzati politikát alakítja ki. A továbbfejlesztését a Nemzetközi SSADM Felhasználók Csoportja (International SSADM User's Group, ISUG) illetve egy arra illetékes testülete felügyeli. A Brit Számítógéptudományi Társaságon belül (British Computer Society, BCS) létezik egy olyan testület, amely a szakmai előírások megvalósulását, azok teljesítésének ellenőrzését egy vizsgáztatási rendszer kialakításával. Az SSADM tulajdonképpen eljárási, műszaki és dokumentációs szabványok gyűjteménye, amelyet úgy terveztek meg, hogy kifejezetten a rendszerelemzést és a szoftverfejlesztést támogassa. Két főrészből áll, az egyik a felhasználói követelmények elemzése, a másik a rendszer tervezése. Ezeket a részeket szakaszokra és lépésekre tagolja. A szakaszok összessége lefedi az adatmodellezés technikáit, a követelményelemzést és a szoftver tervezést. Az SSADM egyik legfontosabb tulajdonsága, hogy rugalmas, azaz az adott (fejlesztési) körülményekhez igazítható, továbbá az egyik leghatékonyabb módszer, amely olyan szervezetek rendelkezésére áll, amelyeknek egy szabványos rendszerfejlesztési filozófiára és megközelítésre van szükségük. Az SSADM nyílt rendszer. Ez azt jelenti, hogy nyilvános, bárki számára hozzáférhető, bárki használhatja licenc díj fizetése nélkül, engedélyt sem kell kérni a CCTA-tól. Ez a nyíltrendszer-stratégia egybeesik más egyéb kormányzati, nyílt szabványnál követett eljárással Nagy-Britanniában (pl. OSI, POSIX). Kifejezetten úgy tervezték, hogy a megjelenése a piacot újra szabályozza és a versenyt a termékek és a szolgáltatások (pl. konzultáció) között fokozza, valamint felszabadítsa a piacot azoktól a korlátoktól, amelyet a tulajdonosnak fizetendő licencdíjak jelentenek. Az SSADM stratégia egyik legfontosabb célja, hogy biztosítsa a szolgáltatási piac hatékony működését, a felhasználói igényeket a piaci lehetőségek maximumáig kielégítse. Ily módon a fejlesztésért felelős vezető nem kerül kiszolgáltatott, függő helyzetbe a konzultációt, oktatást és a megvalósítást végző személyektől, ha azokat egy idő után nem találja már a legalkalmasabbnak a feladat ellátására; ilyen esetben a szerződéses partnereket másikkal helyettesítheti anélkül, hogy a befektetések (pénz, idő, stb.) elvesznének. Az SSADM 4.0 és 4.2 verziójában pontos útmutatások találhatók, hogy hol és hogyan alkalmazzák a minőségbiztosítási szabványokat ill. a kapcsolódó eljárásokat, nevezetesen


9/69

az

ISO

9001-t.

Ezek

az

útmutatások

nagymértékben

rögzítik

az

ISO

9001

minőségellenőrzési eljárásai bevezetésének a módját azok számára, akik ezt alkalmazni kívánják. A projekt vezetést/irányítást a PRINCE módszertan adja, ami jól összeillik az SSADM-mel. 2.1.1 Filozófia Az SSADM alapfilozófiája a különböző nézetek tudatos ütköztetésére, az adatvezérelt, folyamatközpontú és eseményirányított megközelítések tudatos kompromisszumának kialakítására törekszik. Alapvetően felülről-lefelé haladó és adatközpontú elemzési és tervezési módszer, valamint nagy hangsúlyt helyez a felhasználók bevonására. Strukturált módszertan és ezért a tudományos alapúak közé soroljuk. 2.1.2 Modellek: Az entitás-kapcsolat, adatfolyam, entitás-élettörténet és esemény-hatás diagrammok (Jackson-szerű diagrammok) valamint a relációs technika azok legfontosabb eszközök, amelyekkel modellezi, leírja a rendszert. 2.1.3 Életciklus lefedése: Az SSADM nem foglalkozik informatikai stratégiai tervezéssel - (de feltételezi a létét, pontosabban a rövid projekt specifikációk / meghatározások létét) - az opcionális Megvalósíthatósági Tanulmány készítéstől a Fizikai Rendszertervezéséig terjedően fedi le a rendszerelemzés és a - tervezés szakaszait. Vagyis csak részleges, nem teljes az életciklus lefedése. Az SSADM nem foglalkozik a rendszerkészítés, karbantartás, üzembe helyezés, és egyéb kiegészítő területek módszereivel ide értve a projektirányítást is. 2.1.4 Leszállítandó termékek: Alapértelmezésben mindegyik szakasz végén egy pontosan meghatározott dokumentáció készletet kell átadni, amelyeket az adott szakaszban alkalmazott modellezési eljárások és technikák

eredményeit

tartalmazzák,

például

az

adatfolyam

modell

és a

logikai

adatszerkezet dokumentumait. 2.1.5 Előfeltételezések: Az SSADM feltételezi, hogy a rendszerfejlesztés célja egy információrendszer létrehozása, azaz egy adatbázis-központú, tranzakció-orientált rendszer elkészítése. Feltételezi, hogy létezik a szervezet meghatározott, kezelhető méretű részére vonatkozó projekt alapító okirat, amire alapozva indulhat a munka. Továbbá a szervezetben van elfogadott projektirányítási módszertan és gyakorlat, valamint több területre kiterjedő szabályok, helyi szabványok és előírások (szervezeti és alkalmazási szintű felhasználói felület tervezési útmutatók, programozási, kódolási, biztonsági szabványok, stb.).


10/69

2.2 Döntési pontok A hagyományos rendszerfejlesztési eljárásokban a végfelhasználók meglehetősen passzív szerepet játszottak, ők látták el a rendszerelemzőt információkkal és a specifikáció ellenőrzésében valamint a rendszer tesztelésében vettek részt. Azonban semmi esetre sem jöhetett az szóba, hogy befolyásolják vagy megpróbálják befolyásolni a rendszer tervét. Ilyen körülmények között a felhasználó hajlott arra, hogy elfogadja azt a tervet, amit megoldásként adtak neki anélkül, hogy a végfelhasználók kellő időben megkérdőjelezhették volna a terv alkalmasságát. Ennek az eljárásnak aztán számos súlyos következménye támadt. Az SSADM ezzel szemben teljesen eltérő szerepet szán a végfelhasználóknak, ugyanis nekik kell mindazon kritikus döntéseket meghozni, melyek lényegesen befolyásolják a fejlesztés további menetét. Konkrétan három ilyen fontos döntési pont van: • A megvalósíthatósági tanulmány: A rendszer terjedelme, határa, legfontosabb paraméterei, a rendszerfejlesztés stratégiája a végfelhasználók igényének megfelelően az ő egyetértésükkel kerül meghatározásra. • Rendszerszervezési alternatívák: Lényegében azt határozzák meg, hogy a rendszernek tulajdonképpen MIT is kell csinálnia. • Műszaki megvalósítás alternatívái: Ekkor a kiválasztott rendszerszervezési alternatíva lehetséges technikai/műszaki megoldásai közül választanak a végfelhasználók, ezek a megoldások többnyire széles skálán demonstrálják a szóba jövő műszaki opciókat. A kiválasztás megtörténte után világossá válik, hogy a rendszer HOGYAN fogja megvalósítani azt, amit szolgáltatnia kell. Összességében tehát: Az SSADM olyan strukturált rendszertervezési módszertan, amely a fejlesztés elemzési és tervezési fázisait támogatja, és eleget tesz a strukturált módszertanokkal szemben támasztható valamennyi követelménynek. Felépítésében

három

nagyobb

részt

tartalmaz.

Strukturális

része

az

elvégzendő

tevékenységek időbeliségével foglalkozik, technikai része azt mondja meg, hogyan kell a tevékenységeket elvégezni, adatszótára pedig leírja az előállítandó termékeket. 2.2.1 Az SSADM helye az információs rendszerek életciklusában Az SSADM egy sor termék-meghatározást és a kapcsolódó eljárásokat nyújtja az információs rendszerek elemzésének és tervezésének feladataihoz. Ezeknek a leírásoknak a formátuma elősegíti használatukat egy megfelelően tervezett, vezetett és ellenőrzött projektben. A projektirányítás sokféleképpen megszervezhető, ezért nem része az SSADMnek, de létezik ajánlott módszer (PRINCE), amelynek a leírása külön dokumentum. Feltehetően egy SSADM projekt kezdeményezése előtt az üzleti terv, az információs rendszerre vonatkozó informatikai stratégiai terv és a taktikai terv elkészült. Akár formálisan,


11/69

akár nem formálisan, de a fenti dokumentumoknak megfelelő elemzést el kellene végezni egy SSADM projekt kezdeményezése előtt. Általában az alkalmazásokat előállító projektek alapvetően lineáris menetűek, bár lehetnek bennük ismétlődő tevékenységek. A stratégiai tervezés ezzel szemben egy két évtől öt évig terjedő ciklusban ismétli a behatárolást, a meghatározást, a kivitelezést és a felülvizsgálatot, ami sok projektet eredményezhet, köztük olyanokat is, amelyek során az SSADM használható. A következő ábra a stratégiai tervezés, a projektirányítás és az SSADM kapcsolatát szemlélteti.

SSADM

STRATÉGIATERVEZÉS

KIVITELEZÉS ÉS TESZ

MEGVALÓSÍTHA

PROJEKTIRÁNYÍTÁS

FIZIKAI RENDSZERTE

SPECIFIKÁCIÓ LOGIKAI RENDSZER-

KÖVETELMÉNY-SPEC

KÖVETELMÉNY-ELEMZ

TELJESKÖRÛ VIZSGÁLAT

FEJLESZTÉS

MÛKÖDÕ TERMÉK

Az SSADM technikái teljesen lefedik sokfajta alkalmazás fejlesztőinek az igényeit a funkcionális és információs követelmények meghatározására. Ennek ellenére nem árt emlékeztetni arra, hogy az SSADM nem csodaszer, amely egy informatikai rendszer kivitelezésének minden vonatkozását "kezeli". Egy információs rendszer fejlesztésének tipikus menete a következő: • információs rendszerek stratégiai tanulmánya, melyben szerepelnie kell az adott információs rendszer projektjének is (többek között), • megvalósíthatósági tanulmány, • teljes körű vizsgálat (a specifikáció létrehozására), • fejlesztési projekt (a fizikai rendszerterv létrehozására és a rendszer felépítésére). A stratégiai tervezés esetében az SSADM nem használható, bár a technikái közül néhány hasznos lehet a szervezeti működés (üzleti/működési terület) néhány modelljének az elkészítésénél

(pl.

logikai

adatmodellezés és

adatfolyam-modellezés).

Az

SSADM

technikáival nem lehet azonosítani a szervezeti erősségeket és gyengeségeket, a kritikus sikertényezőket vagy üzleti célkitűzéseket, illetve a lehetőségeket.


12/69

A megvalósíthatóság elemzésében viszont az SSADM-et jól lehet használni. Segíthet az elemző csoportnak a javasolható alkalmazások és az informatikai felhasználásában rejlő lehetőségek felderítésében. Ennek ellenére, az SSADM nem ad teljes körű választ, mivel olyan kérdéseket is meg kell vizsgálni, mint például a szervezeti és pénzügyi megvalósíthatóság, amelyeket támogat ugyan az SSADM technikája, de a módszeren kívüli egyéb technikákat és szaktudást is igényelnek. A megvalósíthatósági elemzés adja egy alkalmazást fejlesztő projekt számára a hivatkozási alapokat. Akár volt ilyen elemzés, akár nem, az elemző csoportnak szüksége lesz az ún. "projektalapító okirat"-ra, amely tartalmazza a projekt célkitűzéseit, kiterjedését és korlátait. A teljes körű vizsgálat adja a rendszer üzleti/működési követelményeinek összes részletét, ami három területet érint: • részletesen meghatározott funkcionális és adatokra vonatkozó követelmények, a minőség mérését lehetővé tevő objektív mértékekkel, • logikai rendszerterv, a működés eseményeit és a lekérdezési követelményeket kezelő műveletekkel, illetve a felhasználó kölcsönhatásokkal, • a technikai környezet leírása, a rendszert megvalósító hardver, szoftver és szervezeti elemek leírásával. A fejlesztési tevékenység továbbviszi a projektet. Tartalmazza az SSADM 6. szakaszának ("Fizikai rendszertervezés") tevékenységeit, valamint a kivitelezést és a tesztelést. Ide tartoznak a felhasználók elfogadási eljárásai, valamint a hardver és szoftver beszerzés. 2.2.2 A módszer felépítése Az SSADM-et úgy tervezték, hogy termékek és szolgáltatások infrastruktúrájára épüljön. Ezért a felépítése olyan, hogy van egy ún. törzsrésze — az alapvető SSADM — és vannak hozzá kapcsolódó egyéb útmutatók. A három nézet modellje Az SSADM egy átfogó módszer, ami nem jelenti azt, hogy az alapfilozófiája bonyolult vagy áttekinthetetlen lenne. A módszer segít az elemzőnek olyan keretek felépítésében, amellyel a működési terület igényének világos megértését lehet dokumentálni. Ez azután folyamatosan finomodik, ahogy az igények részleteire vonatkozó tudás egyre pontosabb lesz. Ami ebben segít, az a következő három nézőpontbeli elemzés (a következő ábrán ábrázolva): • funkciók • események • adatok Ez a három nézőpont lehetővé teszi a hibák korai kiszűrését, mind a felhasználói követelmények megértésében, mind pedig a követelmények részletes meghatározásában.


13/69

Egy projekt-munkacsoportnak kell elvégeznie azokat a szerteágazó tevékenységeket, amelyek a rendszerelemzéstől és rendszertervezéstől a projektirányításig, pénzügyi tervezésig és szervezeti irányításig terjednek. Különböző

technikai

kapacitástervezés,

szakértőket

adatbázisok

és

igényelnek

a

különböző

elosztott-rendszererek

területek, tervezése,

mint

például

becslések

és

termelékenység mérése. Az SSADM részéről haszontalan lenne mindezeket az eljárásokat ugyanolyan részletesen tartalmazni, mint a konkrét fejlesztői tevékenységeket. Az SSADM emiatt bizonyos tevékenységeket kívül hagy a módszer részletes leírásán. Ezeknek a szükséges, de kiegészítő, tevékenységeknek a termékeiről általános leírást lehet találni az SSADM termék felépítési szerkezetében.

FELHASZNÁLÓK IGÉNYEI

adatfolyamok

RENDSZER MEGOLDÁSAI

FUNKCIÓK egyedek

események egyedek

adattárak

INFORMÁCIÓ

IDÕ események SSADM NÉZETEK

2.2.3 A módszer célja Az SSADM célja az, hogy segítsen a projekt tagjainak az informatikai stratégia részeként kitűzött információs rendszerre vonatkozó követelmények pontos elemzésében, valamint a követelményeknek

legjobban

megfelelő

információs

rendszer

megtervezésében

és

specifikálásában. Az SSADM használata során végzett munka mindig egy világosan meghatározott projekt része, amelynek két fontos jellemzője van: • rendelkezik egy formális projekt-indítással, amelynek során a projekt tagjai dokumentum formájában megkapják a feladatuk kiterjedését és az általuk elérendő üzleti/működési követelményeket, • rendelkezik egy világosan azonosítható céllal, amely a fizikai rendszerspecifikáció előállítása, és aminek nagyobb részét az SSADM fizikai rendszerspecifikációja alkotja. Ez a fizikai specifikáció két nagyobb részből áll: az adattervből, melyet általában konkrét adatbázis kezelő rendszer fizikai adatbázisának fogalmaival kell meghatározni, illetve a


14/69

feldolgozási tervből, amely a valós világ eseményeire válaszoló felhasználókat támogató rendszer-feldolgozási folyamatokat határozza meg. A feldolgozást olyan részletességgel kell meghatározni, amely nem igényel már további tervezési döntéseket, a megvalósítás nyelvének egyedi kódolási megfontolásait kivéve. Az SSADM moduláris felépítése miatt könnyen alkalmazható a fenti távlati célok helyett reálisabb, közelebbi célokat kitűző projektekben is, így elképzelhető a következő néhány részfejlesztés: • önálló megvalósíthatósági elemzés, amelynek célja a megvalósítási lehetőségek felmérése, • önálló követelményelemzés, melynek célja lehet az aktuális helyzet felmérése és rendszerszervezési javaslatok kidolgozása, • követelmény-elemzés és meghatározás, melynek célja egy igényelt információs rendszer követelményeinek pontos megfogalmazása úgy, hogy kiadható legyen szerződéses formában a további fejlesztés, • technikai környezetre vonatkozó javaslatok kialakítása, egy létező követelményspecifikáció alapján, amely leírja egy információs rendszer megvalósításának technikai lehetőségeit és következményeit. A világosan meghatározott kezdő- és végpontok között az SSADM egy pontos megközelítést tesz lehetővé az elemzés, tervezés és specifikálás tevékenységeit illetően. Magas fokú rugalmasságot enged meg, elsősorban a munka irányításában, ugyanakkor bátorítja és támogatja a szigorúan felépített megoldásokat. A rendszer alapja a követelmény központúság, egy követelmény-meghatározás nevű technikát használ a kritikus követelmények azonosítására. Az elemző csoport figyelmét mindig az új rendszer követelményeire irányítja. Biztosítani kell azt, hogy az elemzés kezdeteitől fogva, még a legáltalánosabb követelményekhez is, objektív mértékeket lehessen rendelni, amivel azonosítani lehet a részletek vizsgálatának módját a három nézőpont szerint. A követelményjegyzék olyan központi dokumentum, amely a projektirányítás és a fejlesztők részére a projekt során végig látható. Ez a technika az első modul legelső lépésében elkezdődik, ahol a munkacsoport figyelmét a működési terület felhasználóira és funkcióira irányítja. A technikát arra kell használni, hogy pontosítsák a projektindító anyagokat, melyek előző stratégiai illetve megvalósíthatósági tanulmányokból származnak. A követelmény-elemzés során a követelményjegyzék létrehozása és fejlesztése a fő célkitűzés. Hangsúlyt kell fektetni mind a funkcionális, mind a nem-funkcionális követelményekre, világos és objektív mértékeket alkalmazva a megfogalmazásban. Ezen a módon a követelmény-meghatározás hozzájárul a tesztelési kritériumok kialakításához.


15/69

A követelmény-meghatározási tevékenység mindig a jövőbeli rendszerre vonatkozik. Az 1. szakaszban, a jelenlegi helyzet felmérésénél, a létező számítógépes rendszereket lehet modellezni, de ha nincsenek ilyenek, akkor a felhasználók által tervezett jövőbeli rendszert kell modellezni. A rendszer két párhuzamos nézete (adatfolyam-modell és logikai adatmodell) az elemzők követelményekre vonatkozó tudását tükrözik. Ennek az az előnye, hogy a követelmények természetes nyelven megfogalmazott leírását ki lehet egészíteni az ábratechnikák nagyobb pontosságával. Ahogy a követelményjegyzéket ismétlődő módon kiegészítik a 3. szakaszban, a követelmény-specifikáció létrehozása során, a bejegyzések többségét kiterjesztik, felbontják és átalakítják funkciók, adatok és események részletes leírásaivá. A követelmény-specifikáció több különböző részletes specifikációs termék együttese, amely a rendszer iránti igények teljes kifejezését adja. Ahogy az elemzés specifikálássá fejlődik, az információ összegyűjtése három részletes módon történik: • felhasználói kapcsolódásra vonatkozó anyag összegyűjtése a dialógustervezés segítségével, • feldolgozásokra vonatkozó anyag összegyűjtése a funkció meghatározás segítségével, • információs követelmények összegyűjtése a logikai adatmodellezés segítségével.

2.3 A módszer rövid áttekintése, szakaszok 2.3.1

Megvalósíthatóság-elemzési modul (FS)

Ez a modul egyetlen szakaszból áll. A cél az, hogy egy nagyobb fejlesztés elindítása előtt kiértékeljék a működési és technikai követelmények kielégítésének lehetőségeit a költségekhez és várható haszonhoz viszonyítva. Az SSADM nem ír le olyan technikákat, amelyekkel a szervezet stratégiai és üzleti céljait meg lehetne határozni, a várható szervezeti hatásokat, kockázatokat fel lehetne mérni, a kiadásokat és bevételeket meg lehetne becsülni. Ezek a tevékenységek alkotják a megvalósíthatósági elemzés legfontosabb elemeit és ezeket a módszeren kívüli eszközökkel kell végrehajtani. Amit a módszer nyújt, az az adatfolyam-modellezési és adatmodellezési technikák, illetve a követelmény-elemzés felhasználása a jelenlegi rendszer, a szóba jöhető alternatívák és a választott megvalósítási alternatíva vázlatos leírására. Amennyiben egy megvalósíthatósági elemzést a módszer által előírt technikák felhasználásával elvégeztek, úgy a fejlesztési projektet könnyebben lehet indítani és biztosabb becsléseket lehet adni a projekt terveiben.


16/69

2.3.2

Követelmény-elemzési modul (RA)

A követelmény-elemzés a módszeren belül a felhasználói követelmények felmérésére irányul, ami után a működési követelmények kielégítésének különböző lehetőségeit kell megfogalmazni és elő kell segíteni a felhasználók döntését a fejlesztés további menetéről. Két szakaszból áll ez a modul: • Jelenlegi helyzet vizsgálata • Rendszerszervezési alternatívák 2.3.3

A jelenlegi helyzet vizsgálata

A jelenlegi helyzet felmérésével az elemzők megismerik a jelenlegi működési környezetet, közös nyelvet alakítva ki a felhasználókkal. A cél az, hogy meghatározzák a jelenlegi környezetben jól működő dolgokat, amelyeket az igényelt rendszer meghatározásában is szerepeltetni kell, illetve a jelenlegi környezet hiányosságait, hibáit, amelyeket az igényelt rendszerben meg kell szüntetni. A jelenlegi környezet elemzése során dokumentálni kell azokat a követelményeket is, amelyek kifejezetten az új rendszerre vonatkoznak. Három technikát kell itt alkalmazni. Egyfelől a jelenlegi környezet folyamatainak fizikai és logikai képét kell kialakítani, az adatfolyam-modellezési technika segítségével, másfelől a jelenlegi környezet

információ-szerkezetét

kell

meghatározni,

a

logikai

adatmodellezés

felhasználásával. A harmadik felhasznált technika a követelmény-meghatározás. Ez önálló tevékenységként is szerepel, mivel az új rendszerre vonatkozó követelményeket a jelenlegi helyzettől függetlenül is meg kell határozni. A két előzőleg említett technika alkalmazása során is meg kell határozni követelményeket, nevezetesen azokat, amelyek a jelenlegi környezettel függenek össze, a megfelelő illetve nem megfelelő működéseket írják le. Az elemzés során előállított nagyobb termékek a következők: • • • •

Jelenlegi környezet fizikai adatfolyam-modellje Jelenlegi környezet logikai adatmodellje Jelenlegi környezet logikai adatfolyam modellje Követelményjegyzék

Jelenlegi környezet fizikai adatfolyam-modellje A jelenlegi környezet folyamatait az adatfolyam-modellezési technika segítségével lehet felmérni. Ez leírja a nagyobb külső objektumokat a rendszeren kívül, amelyek információk forrásai illetve befogadói, a rendszeren belüli folyamatokat, az adatok lerakatait, amelyek időlegesen tárolják az információt, és a közöttük lévő adatfolyamokat. A létrejövő ábrákat ki lehet egészíteni mögöttes leírásokkal a feldolgozási folyamatok részleteiről és az elemi adategységekről, amelyek mozognak a rendszerben. A rajzolás során tisztázódik a felmérés alá vont rendszer kiterjedése, főbb felépítése és működése. A cél az, hogy a jelenlegi fizikai folyamatokat írják le, az összes hiányossággal, felesleges ismétlődéssel és hibával együtt.


17/69

Ezt

a

leírást

fel

lehet

használni,

mint

hivatkozási

alapot

a

követelmények

megfogalmazásához. Jelenlegi környezet logikai adatmodellje A jelenlegi környezet által tárolt illetve nyújtott információk szerkezetét és tartalmát a logikai adatmodellezés technikájával lehet meghatározni. Ez a meghatározás eleve logikai, mivel a jelenlegi környezet adatai fizikailag nem biztos, hogy bármilyen egységet alkotnak, valószínűleg

eltérő

adathordozókon,

lazán

vagy

egyáltalán

nem

kapcsolódó

adatállományokban, illetve részben papíron vagy "fejben" léteznek. A cél az, hogy meghatározzuk a logikailag összetartozó elemi adatok csoportjait és a csoportok (egyedek) közötti összefüggéseket, egy olyan statikus, általános leírást adva, amely az adatokat áttekinthető szerkezetbe fogja össze, és amely egyaránt képes az összes létező adat előfordulást tárolni, illetve az ismert információs igényeket kielégíteni. Az adatszerkezeti ábrát kiegészíti háttérleírás az egyedekről, kapcsolatokról és az adatelemekről, de itt még nem kell teljes leírást adni. Logikai adatfolyam modell A jelenlegi környezet folyamatainak fizikai vonatkozásait itt meg kell szüntetni, az adattárolási kettősségeket fel kell oldani, a folyamatokat logikus szerkezetbe kell rendezni. Itt kell összevetni a folyamatokat az adatokkal, egy olyan megfeleltetést adva, amely kizárja, hogy a folyamatok által használt különböző adattárak ugyanazokra az adatokra vonatkozzanak. A cél az, hogy meghatározott szabályok alkalmazásával kiszűrjük (és a követelmény jegyzékben szükség esetén rögzítsük) a fizikai elemeket és a felesleges többszörözéseket a fizikai folyamatok modelljéből, kialakítva egy olyan logikai képet a működésről, amely valószínűleg az új rendszerben is érvényes lesz. Ez a logikai kép lehet az alapja a további lépéseknek, azaz a rendszerszervezési alternatívák kiválasztásának és az igényelt

rendszer

meghatározásának.

A

logikai

adatfolyam

modellt

a

szokásos

háttérleírásokon kívül ki kell egészíteni egy olyan leírással, amely összeköti őt az adatszerkezettel, megfeleltetve a logikai adattárakat az adatszerkezetbeli egyedek csoportjainak. Követelményjegyzék A követelményjegyzékben kerülnek feljegyzésre a jelenlegi rendszerrel kapcsolatos illetve az új rendszerre vonatkozó követelmények. A cél az, hogy megfogható, számszerűsíthető módon legyenek a követelmények megfogalmazva, úgy, hogy a követelmények által kitűzött cél elérését később objektív módon lehessen mérni.


18/69

2.3.4

Rendszerszervezési alternatívák

Ez a szakasz teszi teljessé a követelmények elemzését. A jelenlegi környezet felmérése során felderített követelmények (hiányosságok, hibák és továbbvihető tulajdonságok) illetve az új rendszerrel szemben támasztott új követelmények alapján lehetséges alternatívákat kell felkínálni a felhasználói vezetés számára. Olyan alternatívákat, amelyek mind kielégítenek egy alap követelményszintet és különböző jellegű és tartalmú működést jelentenek.

Az

alternatívák

közül

a

projekt

vezetőségnek

ki

kell

választania

a

legmegfelelőbbet, ami jelentheti több alternatíva javaslatainak a kombinációját. Sok olyan technikával kell alátámasztani az egyes alternatívákat, amelyek nem SSADM technikák, mint kockázatelemzés, hatáselemzés, költség- haszon elemzés. A módszerből az adatfolyam modellezést és a logikai adatmodellezést lehet felhasználni az egyes alternatívák alátámasztására, illetve a követelmény meghatározást az alternatívák meghatározására. A szakasz célja az, hogy lehetőséget nyújtson a vezetésnek a projekt céljainak, várható hasznának, kiadásainak újraértékelésére, a pontos követelmények ismeretében. Ha volt megvalósíthatósági elemzés, akkor ebben a szakaszban fel lehet használni az eredményeit és esetleg kevesebb alternatívát kell kialakítani. A választott, illetve kialakított, alternatívát részletesebben meg kell határozni úgy, hogy megfelelő kiindulópont legyen az igényelt rendszer követelményeinek specifikálásához. 2.3.5 Követelmény specifikációs modul (RS) Ez a modul egyetlen szakaszból áll, és ez a "Követelmények meghatározása". A modul célja az, hogy olyan részletes specifikációt állítson elő az igényelt rendszerrel szembeni követelmények meghatározására, amelyet kiindulásként lehet használni a további fejlesztés, esetleges külső szerződő féllel történő, indítására. A követelményeket mérhető formában kell megadni, megfelelő részletességgel. Igényelt rendszer adatfolyam modellje A szakasz első lépéseként a jelenlegi környezet logikai adatmodelljét a választott rendszerszervezési alternatíva és az új követelmények figyelembevételével át kell alakítani, részletesen meghatározva az igényelt rendszer adatfolyam modelljét. A cél az, hogy olyan részletességű leírás készüljön az igényelt rendszer folyamatairól, ami alapján majd azonosítani lehet a rendszer funkcióit és eseményeit. Ez a modell kiindulási alapja lesz a funkció meghatározásnak és hivatkozási alap lesz az egyed-esemény modellezésben, mivel tartozni fog hozzá egy logikai adattár-egyed megfeleltetés, ami kapcsolatot teremt a folyamatok és az adatok között. A szakasz végtermékei között az adatfolyam modell nem szerepel.


19/69

Igényelt rendszer logikai adatmodellje Ezt az adatmodellt a szakasz elején az adatfolyam modellel párhuzamosan kell kialakítani, a jelenlegi környezet logikai adatmodelljéből, figyelembe véve a választott rendszertechnikai alternatívát és az új követelményeket. A cél az, hogy részletesen meghatározzuk a rendszer adatait, úgy, hogy azt később a logikai illetve fizikai tervezésben fel lehessen használni. Ez az adatmodell a szakasz egyik végterméke és a szakasz során folyamatosan össze kell vetni az elkészülő termékekkel, módosítva, ha szükséges. A szakasz során van egy olyan lépés, amely kifejezetten a logikai adatmodell ellenőrzésére szolgál a relációs adatelemzési technika használatával. Ennek során a rendszer kritikus kimenetei és bemenetei alapján egy formális szabályokkal meghatározott tevékenységet elvégezve meg kell határozni az információs igényeknek legjobban megfelelő, alacsony szintű ismétlődéstől mentes, optimális adatelrendezést, és össze kell azt hasonlítani az adatmodellel. Az eltéréseket ki kell értékelni és szükség esetén módosítani kell a logikai adatmodellt. A relációs adatelemzés után megerősített adatmodellt a funkciók feldolgozási folyamatainak meghatározásához kiindulási alapként kell felhasználni. Funkció leírások Az igényelt rendszer adatfolyam modelljéből kiindulva részletesen meg kell határozni a rendszer funkcióit. Itt az a cél, hogy egy olyan dokumentum készüljön minden funkcióról, amely a szöveges leíráson kívül hivatkozik az összes alkotóelemére az adott funkciónak, meghatározva a részletes feldolgozási folyamatokat, összekapcsolva a folyamatokat az adatokkal. A funkció leírás az egész további fejlesztés során fennmarad és egyre újabb részekkel egészül ki, egészen a fizikai megvalósításig. Ebben a szakaszban meg kell határozni a funkciók működését kiváltó eseményeket (módosító funkcióknál), a funkciók bemenő és kimenő adatait és szerkezetüket, valamint a funkciókhoz tartozó mérhető követelményeket (szolgáltatási szinteket). A funkciók feldolgozási folyamatait más technikákkal kell kialakítani. A lekérdező funkciókhoz a logikai adatmodellezés technikájának részeként a lekérdezési utakat kell meghatározni, megadva a lekérdezés adatainak előállításához szükséges utat (egyedeket), amelyet a logikai adatszerkezeten kell bejárni. A módosító funkciókhoz tartozó feldolgozási részleteket az egyed-esemény modellezés során kell meghatározni. Specifikációs prototípus A rendszer kritikus funkcióira el lehet készíteni egy specifikációs prototípust. Ennek a célja az, hogy ellenőrizni lehessen a felhasználókkal együtt a rendszer követelményeinek a helyes megértését, ezért hívják specifikációs prototípusnak. Nem cél az, hogy a prototípust a fizikai megvalósítás során felhasználják. A szakaszon belül a funkciók kezdeti azonosítása után


20/69

lehet előállítani. Az eredményeit fel lehet használni a követelmény specifikáció bármely elemének a módosítására, elsősorban a funkció leírások bemenő és kimenő adatainak leírásánál. A felhasználók által javasolt dialógus részleteket a logikai illetve fizikai tervezés során lehet felhasználni (pl. menüszerkezetek, tájékoztatási követelmények, szolgáltatási szintek stb.) Feldolgozás meghatározása Ez egy közös név a módszer 360. számú lépésének termékeire, ami az egyed élettörténeteket, esemény kölcsönhatási ábrákat és lekérdezési utakat jelenti. Az egyed élettörténetek célja az adatbázist módosító események szabályszerűségeinek felderítése, egyedenként meghatározva a rendszer mögöttes működését, minden olyan szabályt, amely nem fejezhető ki az adatok statikus szerkezetével. Az események hatásait egyedenként felsorolva azonosítani lehet a feldolgozási folyamatok alapműveleteit, amelyeket majd a logikai tervezés során kell feldolgozási folyamatokba szervezni. Az esemény kölcsönhatási ábrák eseményenként sorolják fel az elérendő egyedeket, hasonlóan a lekérdezési utakhoz, meghatározva az esemény által elindított feldolgozási folyamat által bejárt utat az adatszerkezeten. Ezekből az ábrákból fog a logikai tervezés feldolgozási folyamatokat szervezni. A lekérdezési utak a lekérdező funkciókhoz, illetve funkció részekhez határozzák meg a bejárandó utat a logikai adatszerkezeten. Ezekből az ábrákból fog kiindulni a lekérdező feldolgozási folyamatok logikai tervezése. Követelményjegyzék A szakasz során a követelményjegyzék bejegyzéseit fokozatosan az előálló specifikáció egyes elemeihez kell kötni. A szakasz végére nem maradhat olyan követelmény, amelyhez ne tartozna valamilyen specifikáció részlet. A nem-funkcionális követelményeket is teljes mértékben meg kell határozni, mert ezek alapján lehet majd a rendszertechnikai alternatívákat megadni és később a fizikai tervezésnél a teljesítményt optimalizálni. 2.3.6 Logikai rendszerspecifikációs modul (LS) Ez a modul két szakaszból áll: • Rendszertechnikai alternatívák • Logikai rendszertervezés. A cél az, hogy olyan specifikáció álljon össze, amely alapján a fizikai tervezést és megvalósítást ki lehet adni szerződéses külső feleknek, illetve az esetleges későbbi módosítási igényeket (pl. technikai környezet változás) meg lehet valósítani (ha nem változnak az alapkövetelmények, akkor a fejlesztést elég a logikai rendszerspecifikáció alapján újra elvégezni).


21/69

2.3.7 Rendszertechnikai alternatívák A rendszertechnikai alternatívák kialakításának az a célja, hogy lehetőséget adjon a vezetésnek több megvalósítási és üzemeltetési környezet közüli választásra. A választás jelentheti több javasolt alternatíva elemeinek kombinációját is. Minden alternatívának ki kell elégítenie a kötelező jellegű követelményeket, különös tekintettel a nem-funkcionális követelményekre. A kiválasztást segíteni kell költség-haszon elemzéssel, hatáselemzéssel, kapacitástervezéssel. A kiválasztott hardver és szoftver környezetet le kell írni olyan szinten, hogy a fizikai tervezést annak alapján el lehessen kezdeni. 2.3.8 Logikai rendszertervezés A Logikai rendszertervezés során részletes specifikációt kell kialakítani a rendszer belső feldolgozási folyamatairól és külső, felhasználói felületéről. Olyan részletességgel kell ezt megtenni, hogy a fizikai tervezésnél már ne kelljen a feldolgozási folyamatokat a funkcionális, működési oldalról vizsgálni és koncentrálni lehessen az alacsony szintű összetevők fizikai specifikálására. A feldolgozási folyamatok specifikálásánál a Jackson strukturált programozás alapelveit és jelöléstechnikáját használja fel a módszer, kisebb kiegészítésekkel. A cél az, hogy a választott technikai környezet leírásából és a logikai rendszertervből előálló logikai rendszerspecifikációt önállóan lehessen felhasználni a fizikai tervezésnél. A logikai tervezés a rendszer karbantartása miatt is nagyon fontos, mivel elválasztja a követelmények specifikációját és a fizikai specifikációt. Egy esetleges technikai környezetbeli változást elég a fizikai specifikáció szintjéről kiindulva kezelni. Egy működési követelményekben bekövetkező változást elég a logikai specifikáció szintjén kezelni, a módosításokat itt átvezetni. Módosító feldolgozási modellek Az egyed-esemény modellezés termékeiből kiindulva itt részletesen meg kell határozni a módosító (aktualizáló) folyamatok belső szerkezetét és a szerkezethez tartozó elemi műveleteket és feltételeket, meghatározva az adatokkal kapcsolatos hibakezelést is. Minden eseményhez készül egy ilyen modell, amelynek a szerkezetét az eseményhez tartozó esemény kölcsönhatási ábra alapján kell kialakítani, figyelembe véve a

szigorú

sorrendiségeket a funkció leírás alapján. Az így létrejövő feldolgozási szerkezethez műveleteket kell rendelni. A működés lényegéhez tartozó aktualizáló műveleteket az egyed élettörténeti ábrák alapján lehet összegyűjteni. Ezeket a műveleteket, kiegészítve adatbázis navigálási és hibakezelési műveletekkel, kell a szerkezet megfelelő részeihez rendelni. A feldolgozási szerkezet elágazásaihoz és ismétlődő csoportjaihoz feltételeket rendelve készülnek el végül a módosító feldolgozási modellek. Ezek a modellek lesznek a belső feldolgozási folyamatok fizikai tervezésének alapjai.


22/69

Lekérdező feldolgozási modellek A módosító modellekhez hasonlóan itt is az a cél, hogy a belső feldolgozást meghatározzuk. A kiindulópontot itt a lekérdezési utak jelentik, ezek alapján kell létrehozni a feldolgozási szerkezeteket. Figyelni kell a kimeneti adatok és az adatbázis szerkezete közötti szerkezeti (strukturális) ütközésekre. Ezek egy részét itt nem lehet feloldani, de fel kell jegyezni őket a fizikai tervezés részére. Az elemi műveleteket a lekérdezések esetében nincs honnan összegyűjteni, mivel nem szerepelnek az egyed élettörténetekben, így itt kell ezeket meghatározni. A feldolgozási szerkezethez rendelve a műveleteket és feltételeket előállnak a lekérdező folyamatok modelljei. A rendszer felhasználói felületének termékei Itt a dialógustervezés segítségével elő kell állítani azokat a leírásokat, amelyek meghatározzák a felhasználó rendszeren belüli "mozgását", funkciókon belül és funkciók között egyaránt. A cél az, hogy a funkcióleírások, a belépő és kilépő adatok szerkezete és a követelmény jegyzék alapján olyan logikai leírás keletkezzen, amelyik nem fizikai korlátokat vesz figyelembe, hanem a felhasználó nézőpontjából határozza meg a rendszer feldolgozási folyamatainak egységeit, azokat a logikai adatcsoportokat, amelyekkel a felhasználó kapcsolatba kerül, a lehetséges útvonalakat, ahogyan ezek között a csoportok illetve feldolgozási egységek között közlekedik, a tájékoztatás lehetőségeit. Az esetleg elkészített és kiértékelt specifikációs prototípus alapján a kritikus dialógusokat könnyebben meg lehet határozni. Az eredmény egy olyan termékhalmaz, amely dialógusokra osztja fel a rendszer működését, meghatározza a dialógusok szerkezetét, belső bejárását és tartalmát (dialógus vezérlési táblázatok, dialógus szerkezetek), illetve meghatározza a dialógusok szintjén a tájékoztatási igényeket, a dialógusok közötti általános és egyedi mozgási lehetőségeket (dialógusszintű információnyújtás, menüszerkezetek, parancs-szerkezetek). 2.3.9 Fizikai rendszertervezési modul (PS) Ez a modul egyetlen szakaszból áll:

"Fizikai

rendszertervezés".

A

logikai

rendszerspecifikációból és a technikai környezet leírásából kiindulva meg kell határozni az adatok és folyamatok fizikai részleteit. Itt végződik az SSADM módszer, tehát a fizikai megvalósítás már nem tartozik ide. A fizikai rendszertervezéshez a módszer nem ad pontos technikákat és termékleírásokat, mivel azok függenek a kiválasztott technikai környezettől. Inkább általános irányelveket ad a megvalósítás tervezéséhez. Fizikai adatterv Ez az egyik végterméke ennek a szakasznak. A logikai adatmodellből kiindulva el kell készíteni egy kezdeti adattervet, figyelembe véve a technikai környezet előírásait, lehetőségeit és korlátait. A nem-funkcionális követelmények és a funkcióleírások


23/69

szolgáltatási szintre vonatkozó követelményei alapján meg kell becsülni, hogy a kezdeti adatterv megfelel-e az igényeknek (tár- és időigény becslés). Ha nem, és csak akkor, optimalizálni kell a fizikai adattervet, illetve esetleg jelezni kell további feldolgozási részletekre vonatkozó követelményeket (pl. rendezés). Ha az optimalizálás során a fizikai adatterv jelentősen eltávolodik a logikai adatmodelltől, akkor azt majd a folyamat-adat kapcsolat kialakításakor kezelni kell. A fizikai adatterv jelentheti a konkrét adatbázis létrehozását az adott technikai környezetben, mivel ez nem jelent sokkal több erőfeszítést az adatterv leírásánál. Mindenképpen el kell azonban készíteni egy adatbázis specifikációt, mivel a rendszer karbantartása során erre szükség lesz. Fizikai folyamatterv Itt kell specifikálni, a technikai környezet előírásainak, korlátainak és lehetőségeinek figyelembevételével a funkciók minden komponensét. A funkciók logikai komponenseihez hozzá kell rendelni a fizikai megvalósítás részleteit. Ez azt jelenti, hogy létre kell hozni egy funkció-komponens megvalósítási tervet, amelyben az összes funkció minden logikai eleméhez (komponenséhez) meg kell határozni a megvalósításának módját (fizikai alkotóelemét), különös figyelmet szentelve a kettőzések elkerülésére és a közös részfeldolgozások kiemelésére (újrafelhasználás). Ehhez a tervhez kapcsolódóan, azokat a komponenseket, amelyeket nem-procedurális módon meg lehet határozni, részletesen le is kell írni, illetve a technikai környezet számára létre kell hozni (fizikailag meg kell valósítani). Ennek az az oka, hogy a nem-procedurális részek megvalósítása közelebb áll a tervezéshez, mint a hagyományos megvalósításhoz és lehetővé teszi, hogy az alacsony szintű részleteket már a technikai környezet önállóan kezelje (alkalmazás generátorok, negyedik generációs nyelvek stb.). Természetesen itt nincs szó arról, hogy a megvalósítás olyan tevékenységeit, mint tesztelés, hibajavítás, itt el kellene végezni. Azokhoz a funkció elemekhez, amelyeket nem lehet nem-procedurális módon meghatározni, el kell készíteni egy részletes fizikai specifikációt. Itt kell kezelni a logikai tervezés során felderített strukturális ütközési eseteket, amelyek esetleg olyan feldolgozási részleteket igényelnek, mint sorbarendezés vagy adatok ideiglenes tárolása. Folyamat-adat kapcsolat A fizikai folyamatterv a logikai adatmodellen alapul, mivel a felhasználók a rendszer karbantartása során abból kiindulva látják át az esetlegesen módosítani kívánt adatokat, illetve a rendszer használata során utalhatnak rá (pl. ad-hoc, felhasználó által összeállított lekérdezések esetén). Ha a fizikai adatterv az optimalizálás során jelentősen eltávolodna ettől a logikai adatmodelltől, akkor léte kell hozni a folyamat-adat kapcsolatot, amely a fizikai folyamatok számára a fizikai adatokat a logikai adatmodellnek megfelelően láttatja. Megfelelő adatbázis kezelő eszköz használatával a folyamat-adat kapcsolat egyszerűen


24/69

létrehozható vagy eleve szükségtelen. Adatbázis kezelő rendszer nélkül a folyamat-adat kapcsolat létrehozása a fizikai tervezés és megvalósítás során szükséges erőfeszítések mértékét jelentősen megnöveli.

2.4 SSADM és információbiztonság Az informatikai stratégia a szervezeti célok eléréséhez szükséges informatika-alkalmazások célkitűzéseinek és a célelérés módjának együttes áttekintése. A szervezet informatikai stratégiája a szervezeti stratégia része. A szervezeti stratégiában elfoglalt helyét a szervezet informatikához kötődő folyamatai határozzák meg. Nevezetesen, hogy a legtöbb szervezeti tevékenység informatikai elemeket tartalmaz, a szervezeti célelérés informatika-alkalmazás nélkül a folyamatok többségében nem lehetséges. Különösen nagy jelentőségű az informatikai stratégia azon szervezetek esetében, melyek alaptevékenysége az információfeldolgozás. Egyéb részek (részstratégiák) mellett ugyancsak integráns eleme a szervezeti stratégiának a biztonsági stratégia. A szervezet célelérését szolgáló tevékenységek végrehajtásának biztonságát szavatoló feladat- (és ebből adódó folyamat-) rendszernek a szervezeti stratégia által érintett összes tevékenységet le kell fednie. Enélkül ugyanis a biztonság teljes körűsége és az egységes biztonsági szint követelménye sérülne. A követelmények szükségessége könnyen belátható. Feltéve, hogy a szervezet a célelérést szolgáló folyamatok nem minden elemének

működőképességét

tudja

biztosítani,

az

adott

elem

lehetséges

funkciócsökkenéséből (vagy diszfunkcionalitásából) adódó téves célelérési tevékenységek a rendszer-elv alapján, az önmagában talán "biztonságos" többi folyamatot is veszélyezteti. Fenti megállapításhoz két megjegyzés szükséges: • A biztonság komplex kategória, tehát - épp az előzőek alapján - különválasztva nem értelmezhető egyes részrendszerek vagy elemek saját biztonsága (ezért az idézőjel). • Az informatikai biztonság a jelen megközelítés keretei közt nem más, mint a szervezeti tevékenységek informatikai összetevőinek a célok eléréséhez szükséges (megfelelő) állapotban tartása. Következésképpen az informatikai biztonság integráns része az informatikai rendszernek és egyúttal a szervezeti szintű biztonsági rendszernek is. Köztük szoros kölcsönös kapcsolati mechanizmus érvényesül, ezért nem is mindig lehetséges az egyes elemek elhatárolása, vagy közöttük szigorúan oksági kapcsolat definiálása. Az informatikai stratégia követelményeket fogalmaz meg. A követelmények közt biztonsági szempontból lényeges elvárások is megjelennek, amelyek a rendszertervezés számára célkitűzésként fogalmazódnak meg. A későbbiekben ezek alapját képezik az informatikai rendszer, az informatikai biztonság tervezésének, majd megvalósításuknak. Példák


25/69

bizonyítják, hogy az informatikai rendszer létrehozása után pótlólagosan végrehajtott biztonsági intézkedések, utólagosan beillesztett biztonsági mechanizmusok nemcsak többszörös költséggel valósíthatók meg, de az általuk elért biztonság mértéke sem azonos a rendszerkialakítással egy időben és szoros kapcsolatban végrehajtott biztonsági fejlesztés eredményével. A sikeres rendszerműködésnek biztonsági kritériumai is vannak. A gyakorlatban ezek a biztonsági kritériumok rejtetten vannak jelen. A biztonságnak, mint szükséges funkciónak feltárásához és megjelenítéséhez a szervezet tevékenységének teljes körű átvilágítására és részletes funkcióelemzésére van szükség. Az ennek nyomán feltárt biztonsági funkció az elemzések nyomán kritikus sikertényezővé válhat. Az informatika biztonsági kérdéseinek kritikus sikertényezővé (KST) való nyilvánítása szükséges ahhoz, hogy az informatikai célok között a biztonságos informatikai rendszer megteremtésének - vagy a biztonság fenntartásának illetve megerősítésének - célja megjelenjen. A funkcióelemzés - KST célrendszer folyamaton keresztül tisztázott és a stratégiai célrendszerbe beiktatott biztonsági szempontok eredményezik az informatikai stratégiában biztonsági projektek kitűzését. A biztonsági projekt megindításához szükséges biztonsági értékelés jelenti az informatikai biztonság létrehozásának kiinduló pontját. A tervezési folyamatok párhuzamossága és kölcsönösségi viszonya indukálja a tervezési módszerek tervezésének

nagyfokú

párhuzamosságát

módszertana

az

és

informatikai

rokonságát.

Az

rendszertervezés

informatikai

biztonság

módszertanához

sok

tekintetben hasonló. Ilyen például a tervező csoport összetétele, az alkalmazott csoportmódszerek és szervezési résztechnikák, valamint a tervezés során végrehajtott lépések. Az Európai Unió által kidolgozott informatikai és információs rendszerekre vonatkozó biztonsági irányelveket követő különböző szervezési módszertanok (némileg eltérő terminológiával és tartalommal) az informatikai rendszerszervezés szakaszait az alábbiak szerint definiálják. Szervezési lépések az angol SSADM (Structured Analysis and Design Method) szerint: • megvalósíthatóság elemzése, • helyzetfelmérés, • a rendszerszervezési mód meghatározása, • a követelmények megfogalmazása, • technikai alternatívák, • logikai tervezés, • fizikai tervezés. (az SSADM-en kívüli lépések:) • kivitelezés és tesztelés,


26/69

• rendszer működtetés. A vázolt analógiák és beágyazódások ellenére az informatikai biztonság megteremtésének folyamata specifikus feladatokat tartalmaz. Specifikumuk a megoldásukhoz szükséges szemléletmódból és ismeretanyagból fakad. Ezen feladatok módszertani elemeit tartalmazza az informatikai biztonság módszertana. Jelen kézikönyv ezen alapelvek figyelembevételével, adaptálásával és a magyar állam- és közigazgatási rendszerhez való igazodásával, valamint a már közreadott ajánlások alkalmazásba vételével készült. Az IBMK tartalma nem fedi le az informatikai biztonság megteremtésének teljes folyamatát, de bemutatja az informatikai stratégiából adódó, az informatikai rendszerszervezés során tételezett célok biztonsági vetületeinek meghatározásától a konkrét rendszer kialakításához szükséges környezeti és számítástechnikai intézkedések megtervezéséig végrehajtandó lépéseket. A folyamat egyes lépéseinek bemutatásakor utalás történik a kézikönyv kereteit meghaladó feltételekre, illetve lépésekre. Hatékony végrehajtásuk ugyanis csak az egész rendszer működésének szem előtt tartásával történhet. 2.4.1 SSADM követelmény-elemzés és információbiztonság A követelmény-meghatározás során a követelményjegyzéket kell előállítani és folyamatosan bővíteni. Az információbiztonsággal kapcsolatos kérdések lényegében ezen a szinten már bekerülnek a rendszer követelményspecifikációjába. A technika célja Ez a technika vezérli a javasolt új rendszer követelményeinek a feltárását. A célok a következők: • a javasolt rendszerre vonatkozó olyan követelmények azonosítása, amelyek a felhasználók és az üzleti tevékenység igényeit kielégítik • a követelmények leírása mérhető formában • az új rendszerre vonatkozó döntések megalapozása • a részletes követelmény-specifikáció kidolgozása • az elemzésnek a jövőbeli rendszer követelményeire való irányítása A technika rövid leírása A követelmények meghatározása során funkcionális és nem-funkcionális követelményeket kell leírni a javasolt rendszerről. A követelményjegyzék egy központi lerakat, amely információt nyújt a követelményekről és biztosítja a követelmények nyomon követését. Önmagában nem elegendő a pontos specifikációhoz, ezért együtt kell használni egy sor szigorú technikával és termékkel a követelmények teljes specifikációjának az elkészítéséhez. A követelmények meghatározása ismétlődő folyamat, egyre részletesebb leírásokat adva. A követelményeket mindig úgy kell leírni, hogy:


27/69

• mérhetőek legyenek • elegendően részletesek legyenek a kétértelműség elkerüléséhez és a döntések megalapozásához • minimalizálják az ismétlődést a különböző specifikációs termékek között A követelményjegyzéket a logikai rendszer tervezéséig mindenütt ki lehet egészíteni. Az adatfolyam-modellezés és logikai adatmodellezés a kezdetekben segít a követelmények megfogalmazásában. A későbbiekben a logikai adatmodellezés az adatokra vonatkozó követelmények részletes specifikációját nyújtja. A funkció meghatározás a lekérdezésekre és aktualizálásokra vonatkozó követelményeket fejti ki részletesen. A rendszerszervezési alternatívákat a követelményjegyzék alapján kell kidolgozni. A követelményjegyzéket a rendszertechnikai alternatívák kidolgozása során is használni lehet. A követelmény-meghatározás egy sor projekt-eljáráshoz tartozó technikával is kapcsolatban áll: • kapacitástervezés: a követelmény-meghatározással párhuzamosan biztosítani kell, hogy: − megfelelő kapacitás álljon rendelkezésre az új alkalmazás követelményeinek kielégítésére − az új alkalmazás ne érintse hátrányosan a jelenlegi szolgáltatásokat • a szolgáltatási szintre vonatkozó követelmények le legyenek tesztelve a javasolt alkalmazási és technikai környezetben • kockázatelemzés és -kezelés: az információs rendszerek biztonsági követelményeinek a felmérésére szolgáló technikák, amelyek formálisan megbecsülik a fenyegetéseket, veszélyeztetettséget és kockázatot. A követelmény-meghatározásnak együtt kell működnie vele, hogy a biztonsági megfontolásokat figyelembe lehessen venni az SSADM projekt menetével párhuzamosan. • tesztelés: a követelmények mérhető meghatározása alapot nyújt a tesztelési előírások kidolgozásához, amelyek viszont lehetőséget adnak annak felmérésére, hogy az új rendszer kielégíti-e a követelményeket • képzés és dokumentálás: az elemzőknek tudniuk kell, hogy a megfelelő szakértelem és dokumentáció kialakítására vonatkozó követelményeket időben ki kell elégíteni. Ez vonatkozhat a felhasználókra és a támogató személyzetre egyaránt. A követelmények meghatározása Tényfeltárás Különböző megközelítéseket alkalmazhat az elemző a tényfeltárásban: • • • •

felhasználók kikérdezése dokumentumok elemzése speciális kérdőívek a napi munkában


28/69

• megfigyelés • ötletbörze • prototípuskészítés • személyes tudás és ítélőképesség A megfigyelés, dokumentumok elemzése a jelenlegi környezet felmérésében segíthet. Ahogy az elemző egyre többet tud meg a felhasználók igényeiről, lehetővé válik, hogy új követelményeket javasoljon. Ilyen esetekben a felhasználókat is meg kell kérdezni, mert végső soron minden követelménynek a felhasználók a "tulajdonosai". Funkcionális követelmények Ezek a követelmények azt írják le, hogy "mit" kell a rendszernek tudnia. Ilyenek lehetnek például: • • • • •

aktualizálások lekérdezések jelentések/ kimenetek adatok (adatelemek, egyedek, kapcsolatok) más rendszerekkel való kapcsolat

Nem-funkcionális követelmények A nem-funkcionális követelmények azt írják le, hogy hogyan, mennyire jól vagy milyen szintű minőségben kell egy lehetőséget vagy lehetőség csoportot nyújtania a rendszernek. Ezek a követelmények nagyon fontosak a rendszer sikeressége szempontjából. Vonatkozhatnak a rendszer egészére, egyes részeire vagy konkrét funkcionális követelményekre. A következő kategóriákat lehet használni: • Szolgáltatási szintekre vonatkozó követelmények − − működési időszak (hétvége, ünnepnap stb.) − − rendelkezésre állás (a működési időszak százalékában) válaszidők − − − − adatbázishoz fordulások gyakorisága (tranzakciók száma óránként) − − feldolgozási mennyiség (a teljes feldolgozott munkamennyiség időegységenként) kötegelt feldolgozások legkorábbi kezdése/ legkésőbbi befejezése − − − − megbízhatóság (hibák száma adott időszakban, maximális leállási idő, két meghibásodás közötti átlagos idő) • Adathozzáférési korlátozások védelmet igénylő adatok − − olvasás vagy módosítás korlátozása bizonyos felhasználói − − szerepkörökre − − korlátozás szintje (fizikai, jelszavas, titkosított) • Biztonság mentések gyakorisága − −


29/69

− − visszaállítás (prioritások, gyorsaság, aktuálisság mértéke, rendszertükrözés) rendszer összeomlás (kézi rendszer, csökkentett rendszer, tartalék − − rendszer a visszaállításig) • Megfigyelés teljesítmény-figyelés szintje − − − − jelentések tartalma, gyakorisága kihasználtsági szintek figyelése − − − • Auditálás és ellenőrzés− pénzügyi auditálás (hozzáférési korlátozások, felhasználók megosztása, tranzakciók nyomon követése) − − rendszer-auditálás (fontos tranzakciók nyomon követése) − − teljesítmény-auditálás (a várt haszon kiértékelésére vonatkozó statisztikák) ellentmondások kiszűrésének módjai − − − − adatbevitel ellenőrzésének módjai (engedélyezési eljárások) • Korlátozások áttérés a jelenlegi rendszerről (mit kell átalakítani, kell-e párhuzamosan − − működtetni, egy csapásra kell-e áttérni?) − − kapcsolat más rendszerekkel ember-számítógép kapcsolat követelményei − − − − archiválás


30/69

3

Microsoft Solution Framework

3.1 Alapok A Microsoft Solutions Framework (MSF) koncepciók, modellek és gyakorlati tapasztalatok rugalmasan kezelhető és használható összefüggő sorozata, amely technológiai projektek tervezésében, fejlesztésében, kivitelezésében és menedzselésében nyújt segítséget. Az elmúlt évtized során az üzleti világ alapos átalakuláson ment keresztül. A termékfolyamatok

(termékciklusok)

lerövidültek,

a

különböző

osztályok

közötti

adatmegosztás és adatcsere kritikus tényezővé vált, a papírnyomtatványok puszta létezése is gyakran görcsös vánszorgássá alakítja a legegyszerűbb üzleti folyamatokat. A sebesség és az alkalmazkodóképesség kulcsfontosságú tényezőkké váltak az üzleti túlélésben. A szervezeteknek hatékonyan kell irányítaniuk az alapszintű üzleti feladatokat (pl. bérszámfejtés, értékesítés), miközben előrelátóan és kreatívan fel kell mérniük a stratégiai lehetőségeket és meg kell tervezniük az új üzleti megoldások és a gyorsan változó új technológiák bevezetését. Az informatikával foglalkozó szervezeteknek a felhasználható termékek és technológiák széles skálájából kell kiválasztaniuk a saját informatikai megoldásuk felépítéséhez szükséges elemeket. Mindazonáltal, a sikeres megoldások építéséhez gyakran nem áll rendelkezésükre megfelelő segítség. Az IT projektek a fent említett bonyolultság miatt csaknem 70%-ban sikertelenek. A sikertelenség nem feltétlenül jelenti a projekt teljes bukását; általában „csak” az a probléma, hogy a projekttel szemben támasztott elvárásoknak a projekt nem felel meg teljes egészében. A Microsoft Consulting Service 1994-ben ismerte fel a problémát, és létrehozta a Microsoft Solutions Framework-öt, rövidebb nevén az MSF-et. Az MSF keretrendszer a csapatmunka alappillére, mely a módszeres tervezés és dokumentáció révén mind a projektben résztvevő fejlesztők, mind az ügyfél részére lehetővé teszi a fejlesztési munka folyamatos nyomon követését. Az MSF keretrendszer alapelvei biztosítják,

hogy

a

projektek

mindig

a

rendelkezésre

álló

erőforrások

optimális

kihasználásával, de azok túllépése nélkül készülhessenek el. A verziózott kibocsátással az ügyfél jól átláthatja, hogy a számára fejlesztett alkalmazás az aktuális állapotában milyen képességekkel bír, a fejlesztők pedig segítséghez jutnak a határidő-túllépések kockázatának minimalizálásában. A Microsoft Solutions Framework (MSF) koncepciók, modellek és gyakorlati tapasztalatok rugalmasan kezelhető és használható összefüggő sorozata, amely technológiai projektek tervezésében, fejlesztésében, kivitelezésében és menedzselésében nyújt segítséget. Az MSF

irányelvei

és

gyakorlatai

útmutatót

adnak

egy

szervezet

erőforrásainak

összegyűjtésére, a munkaerő koordinálására, menedzselésére és olyan folyamatok


31/69

implementálására, melyek lehetővé teszik a technológiai megoldások, az infrastruktúra és a változó üzleti igények, célok összehangolását, találkozását. A Microsoft Solutions Framework a Microsoft Consulting Service (MCS) tapasztalatait felhasználva készült. Ez a rendszer olyan keretet ad a fejlesztésnek, ami biztosítja a projektek gördülékeny lefolyását. Az MSF spirálmodellre épülő projekt életciklus szemlélete a következőkre alapul: • • • • • • A sikeres

Elképzelés. Vízió (vision) Projekt behatárolás (scope) Alapos tervezés Fejlesztés, telepítés Tesztelés Teszteredmények alkalmazása a következő verzióra projekt alapja, hogy a projekt kezdetén minden résztvevő tisztában legyen a

feladattal, kialakuljon a közös vízió. Ezután el kell dönteni, mi fér bele a projekt első verziójába, mire elég a humán és pénzügyi erőforrás, és nem utolsó sorban az idő. Fontosnak tartjuk tehát, hogy a projekt kezdetén kialakuljon a kölcsönös bizalom, hisz mind a megrendelő, mind a fejlesztő érdeke ugyanaz; rövid idő alatt sikerre vinni a projektet.

3.2 MSF csapatmodell Az MSF csapatmodell elveti az egyszemélyes projektfelelős koncepcióját, mert készítői azt vallják, hogy egy átlagos IT projekt terheit nem képes egyetlen ember a vállán viselni, legyen bármilyen jó szakember. Ha mégis kiváló vezető, akkor is nehézségbe ütközik, hiszen ellentmondásos érdekeket kell magában egyeztetnie. Az MSF csapat ezzel szemben hat egyenlő szerepkörre épül, ahol mindenkinek megvan a maga felelősségi területe, melyek sokszor ellenérdekeltek. A csapat akkor működik jól, ha a hat szerep képviselői konszenzusra jutnak, amire az MSF konkrét utakat, módszereket jelöl ki. A szerepek kisebb projekteknél összevonhatók, így a legkisebb MSF csapat háromtagú lehet. A csapatmodell hat szerepköre és felelősségi területei a következők: • Product Manager felelős az ügyfél elégedettségért, • a Program Manager felelős a fejlesztés gördülékeny haladásáért, • a Development felelős azért, hogy a rendszer a specifikációnak megfelelően, határidőre készüljön el, • a Testing felelős a termék minőségéért, • a User Experience felelős a végfelhasználók igényeinek figyelembevételéért és oktatásáért, • a Release Manager felelős a rendszer üzembe helyezéséért. Jól látszik, hogy a Product Manager és a User Experience között konfliktushelyzet alakulhat ki, hiszen a termékfelelőst az alacsony ár érdekli, míg a felhasználók felelősét a minél 2007.09.05. • Módszertan leírás

32/69

gazdagabb felhasználói élmény, ami pedig költséges. Ezt egy csapat sokkal hatékonyabban tudja feloldani, mint egyetlen felelős. A következő képen összefoglalóan láthatók az MSF szerepek. Fontos, hogy a lépések során mind a hat szerep minden fázisban egyformán aktív. A Testing szerep például már a víziót vagy a terveket is ellenőrzi, teszteli, állandóan hibákat keres. A bugtracking az utolsó három fázis alatt működik, feladata a szoftverben keletkező hibák kiderítése, illetve feldolgozása, fő felelőse a Testing szerep, illetve a Development csapat. A Release Manager szintén már a legelején aktív, minden felmerülő ötletet elemez az üzemeltetés szempontjából, így nem a végén derül ki, hogy egy nagyszerű funkció esetleg nem képes működni a rendszer valós környezetében.


33/69

3.3 MSF folyamatmodell Az MSF folyamatmodellje egy módosított spirálmodellre épül, amely ötvözi a vízesésmodell és a spirálmodell előnyeit. Egy projekt öt fázisból áll. Az első az Envisioning, melynek során megszületik a projekt víziója, és eldöntetik, hogy annak mely részeit fogják a projekt kereteit képezni. − Mérföldkő: az elképzelések, a projekt terjedelmének (scope) elfogadása) A következő rész a Planning, melynek során a vízió megvalósításra kiválasztott részeit részletesen megtervezik és elkészül a projektterv. − Mérföldkő: a projekt tervek elfogadása A harmadik a Development, ennek a végén már késztermék jelenik meg, ami már csak stabilizálásra szorul. − Mérföldkő: a projekt terejdelmének megfelelő alkalmazás elkészül A Stabilizing fázis végén a termék elnyeri végső, telepítésre alkalmas alakját. − Mérföldkő: a release (szoftver, dokumentációk, kiegészítések) elkészül A Deployment fázis során a teljes megoldás a helyére kerül, a projekt végétől már az üzemeltetők veszik kézbe a rendszert. Fontos, hogy a hat szerep minden fázisban egyformán aktív. A Testing szerep például már a víziót vagy a terveket is ellenőrzi, teszteli, állandóan hibákat keres. A Release Manager szintén már a legelején aktív, minden felmerülő ötletet elemez az üzemeltetés szempontjából, így nem a végén derül ki, hogy egy nagyszerű funkció esetleg nem képes működni a rendszer valós környezetében. Összefoglalva tehát elmondható, hogy az MSF folyamatmodell iteratív és inkrementális. A folyamatok iterációkból, ismétlődő fázisokból épülnek fel, amelyek az előző lépésekre építenek.


34/69

A kockázatkezelés a projekt teljes időtartama alatt működik, ez minden csapattag felelőssége. A kockázati tényezőket dokumentáljuk, rangsoroljuk, majd felelősöket rendelünk hozzájuk. Így ha a kockázat problémává válik, azaz bekövetkezik egy nem várt esemény, a valójában várt esemény lesz, és dokumentálva lesznek a tennivalók. A bugtracking az utolsó három fázis alatt működik, feladata a szoftverben keletkező hibák kiderítése, illetve feldolgozása. Fő felelőse a Testing szerep, illetve a Development csapat.


35/69

3.4 Egy tipikus MSF folyamat Egy tipikus MSF fejlesztés a következő lépésekből áll:

Jól látható, hogy a módszertan kiemelt szerepet szán a tervezésre, az igények pontos meghatározására, ez a módszertan egyik alapkoncepciója. A módszertan rendkívül hasznos gyakorlati segítséget ad az IDŐ, FELADAT és ERŐFORRÁS közötti egyensúly konszenzus alapú meghatározására, amellyel a lehető legapróbb részletekig kielemezhető az adott témakörre vonatkozó összes igény, mindkét oldalról. Jellemző a módszertan alaposságára, hogy a projekt elején célszerűen egy közös fogalommagyarázat készül, melyben az elsőre egyértelműnek tűnő szakmai fogalmak közösen megállapított definíciója áll, ezzel a fejlesztés korai szakaszában kiszűrhető a kommunikációs hibák nagy része. Az MSF alapjai a csapatmodell, a folyamatmodell, a proaktív kockázatkezelés, projektmenedzsment, a tudás frissen tartása (readiness) és a korszerű hibakövetés (bugtracking). Ezen modellek alkalmazása több előnnyel is jár, ezek közül a legfontosabb, hogy a csapat tagjai mindig tudják, mi történik, illetve mindig pontosan tisztába vannak azzal, hogy az adott részért ki felelős. Szerep

Célja

Product Management

Elégedett megrendelő

Program Management

A megfelelő termék átadása az ütemezésnek megfelelően

Development

A specifikációban meghatározottak kifejlesztése

Testing

A termék átadása csak az ismert problémák lezárása után történjen meg

User Experience

Hatékonyság- és teljesítménynövekedés a felhasználói munkafolyamatokban

Release Management


Zökkenőmentes telepítés és üzemeltetés

36/69

3.4.1 MSF kockázatkezelés A kockázatkezelés az MSF módszerben is kiemelkedő szerepet kap. A lehetséges kockázati tényezőket időben végig kell gondolnunk, fontos annak hangsúlyozása is, hogy a kockázat egy lehetőség, eshetőség, amely lehet veszély (threat) vagy üzleti lehetőség (option), amely nem feltétlenül következik be, amennyiben azonban igen, akkor a bekövetkezésre előre fel kell készülnünk. Ez igaz természetesen mindenféle biztonsági kockázatra is. Az MSF kockázatkezelés első lépése a kockázatok azonosítása (Identity), ehhez a megfelelő szakterületek szakembereitől szerezhetünk információkat: hol, milyen kockázatok várhatók, milyen váratlan eseményekre kell felkészülnünk. Ezeket az információkat a Risk Statementben fogalmazzuk meg.

Ezután az egyes kockázatok elemzése és prioritási sorrendbe

állítása történik meg (Analyze and Prioritize). Ezután történhet meg a kockázatok kezelésének módjait, esetleges elkerülésük eszközeit és eljárásait (Plan and Schedule). A kockázatkezelés következő lépése a kockázatok bekövetkezésének nyomon követése, annak rögzítése, hogy mi következett be, milyen volt a bekövetkezés gyakorisága éa milyen károk történtek (Track and Report). Ezután az újabb felmerült veszélyforrások felmérése és elemzése történik, illetve az elavult régi kockázatok megfelelő kezelése (Control.) Ezután újra az analízis és priorizálás lépés következhet. Fontos eleme a folyamatnak az, hogy az egész eljárásból tanuljunk (Learn), ennek eredményeiről és az egéyz kockázatkezelési eljárásról egy adatbázist kell fenntartanunk (Risk Knowledge Base, Concepts, and Processes), ez alkalmas arra is, hogy az újabb kockázati tényezőket megfelelően felismerhessük. A kockázatkezelési folyamat vázlatosan a következő ábrán tekinthető át.


37/69

3.4.2

Fejlesztési csapatmodell

A fenti eljárásra alapozva kidolgoztunk egy ún. fejlesztési csapatmodellt, amelynek elemei az MSF-re épülnek. Ez a modell alkalmas tetszőleges méretű rendszerfejlesztési feladatok megoldására, tartalmazza az ehhez szükséges szerepköröket, évek óta hatékonyan működik. A jelen projektben is ez a fejlesztési modellt használjuk a rendszerfejlesztésben.

ROI, munkakörnyezet

idő, költség, feladatok, minőségbiztosítás, adminisztráció, teszt szervezés technológiai és user experience teszt

szponzor

PM

teszt

technológia

Szakmai fejesztési. munka outsource / insource


termék menedzser kereskedelem

marketing

a hasznosító képviselője – user exp.

kereskedelmi stratégia – árképzés és üzleti érték definíciója.; jogi vonatkozások, szerződések; support Marketing anyagok, látványtervek

User képviselet, GUI; oktatás és segédanyagai, bevezetés

38/69

4

Rational Unified Process (RUP)

4.1 A fejlesztés folyamata A Unified Process a rendszerfejlesztés folyamatát alapvetően két dimenzióval írja le. Az egyik dimenzió a fejlesztés időbeliségét, dinamikáját követi. A másik dimenzió statikus szempontja az eljárás elemeit határozza meg, az elkészítendő dokumentumokat, diagramokat és forráskódokat, melyek közvetve az elkészítés lépéseit, munkafolyamatait is megadják. Az időbeliség alapján a Unified Process a rendszerfejlesztést négy nagyobb egységre, négy fázisra bontja: • Előkészítés • Kidolgozás • Megvalósítás • Átadás Az Előkészítés (inception) fázisában a rendszer eredeti ötletét olyan részletes elképzeléssé dolgozzuk át, mely alapján a fejlesztés tervezhető lesz, a költségei pedig megbecsülhetők. Ebben a fázisban megfogalmazzuk, hogy a felhasználók milyen módon fogják használni a rendszert és hogy annak milyen alapvető belső szerkezetet, architektúrát alakítunk ki. A Kidolgozás (elaboration) fázisában a használati módokat, a „használati eseteket” részleteiben is kidolgozzuk, valamint össze kell állítanunk egy stabil alaparchitektúrát (architecture baseline). A Unified Process készítőinek a képe alapján a teljes rendszer egy testnek tekinthető, csontváznak, bőrnek és izmoknak. Az alaparchitektúra ebből a bőrrel borított csontváz, mely mindössze a minimális összekötő izomzatot tartalmazza, annyit, amennyi a legalapvetőbb mozdulatokhoz elegendő. Az alaparchitektúra segítségével a teljes fejlesztés folyamata ütemezhető és a költségei is tisztázhatók. A Megvalósítás (construction) során a teljes rendszert kifejlesztjük, beépítjük az összes „izomzatot”. Az Átadás (transition) a rendszer bétaváltozatának kipróbálását jelenti, mely során néhány gyakorlott felhasználó teszteli a rendszert és jelentést készít annak helyességéről vagy a hibáiról és hiányosságairól. A rendszer javítása a rendszer módosítását, majd ezt követően újabb tesztelést jelent. Minden fázis vége a fejlesztés egy-egy jól meghatározott mérföldkövét (milestone) jelenti, azaz olyan pontot, ahol egy célt kell elérnünk, illetve ahol kritikus döntéseket kell meghozni. Minden fázis végén megvizsgáljuk az eredményeket és döntünk a folytatásról. A fejlesztés nagyobb egységeit jelentő fázisok további kisebb egységekre, iterációkra (iteration) bonthatók. Minden iteráció egy teljes, illetve részben önálló fejlesztési ciklust jelent, mivel az iteráció végén egy működő és végrehajtható alkalmazásnak kell előállnia. Minden 2007.09.05. • Módszertan leírás

39/69

iteráció végén így a végső, teljes rendszer egyre bővülő részét kapjuk eredményül, melyeket a rendszer egymás utáni kibocsátásainak (release), vagy belső változatainak nevezünk. A belső változatok lehetővé teszik, hogy azt a fejlesztők kipróbálhassák és annak tapasztalatai alapján esetleg módosíthassák a fejlesztés ütemezését. A Unified Process felbontásában a fejlesztés menetének másik dimenziója az eljárás elemeit határozza meg, hogy a fejlesztés során milyen dokumentumokat, diagramokat, forráskódokat — összefoglaló néven produktumokat (artifact) — készítsünk el. Az elkészítendő produktumok természetesen a megfelelő tevékenységekkel állíthatók össze, mely tevékenységeket pedig adott szakismerettel rendelkező személyek („dolgozók”), adott sorrendben hajthatnak végre. A tevékenységek, azok időbeli sorrendje és az azt végrehajtó dolgozók együttesen egy munkafolyamattal (workflow) írhatók le. Kezdetben a fejlesztéshez egy megfelelő kiindulópontot keresünk. Az első tevékenységcsoportunk így az üzleti modellezés (business model), mely során megkeressük a készítendő rendszer üzleti vagy más néven szakterületi környezetét, mely alapvetően az üzleti fogalmakat és folyamatokat jelentik, illetve az azokra hatást gyakorló üzleti munkatársakat. A következő tevékenység a követelmények meghatározása (requirements capture). Ezen munkafolyamat során összegyűjtjük és felsoroljuk a rendszer működésével szemben támasztott kezdeti elképzeléseket, leírjuk azt, hogy a rendszernek milyen környezetben kell működnie, valamint felsoroljuk a funkcionális (működéssel kapcsolatos) és nem-funkcionális (pl. válaszidők, bővíthetőség, alkalmazott technológiák, stb.) követelményeket. A követelmények meghatározása során alapvetően a felhasználók szempontjából írjuk le a rendszert, így annak egy külső képét rögzítjük. A következő munkafolyamat, az elemzés (analysis) folyamán a követelményeket a fejlesztők szempontjának megfelelően rendezzük át, így azok együttessen a rendszer egy belső képét határozzák meg, mely a további fejlesztés kiindulópontja lesz. Az elemzés során rendszerezzük és részletezzük az összegyűjtött használati eseteket, valamint azok alapján meghatározzuk a rendszer alapstruktúráját. Az elemzés célja a szerkezeti váz kialakítása, mely vázat a következő munkafolyamat, a tervezés (design) formálja teljes alakká és tölti fel konkrét tartalommal, mely az összes — funkcionális és nem-funkcionális — követelménynek is eleget tesz. A tervezésnek az implementációval kapcsolatos összes kérdést meg kell válaszolnia, így részletesen le kell írni az összes felhasznált technológiát, a rendszert független fejlesztői csoportok által kezelhető részekre kell bontani, meg kell határozni az alrendszereket és közöttük a kapcsolódási módokat, protokollokat. A tervezésnek a rendszert olyan részletezettségi szinten kell vázolnia, melyből az közvetlenül, egyetlen kérdés és probléma felvetése nélkül implementálható. A Unified Process szóhasználata szerint elő kell állítania az implementáció tervrajzát (blueprint).


40/69

Az implementáció (implementation) során a rendszert az UML terminológiája szerinti komponensekként állítjuk elő, melyek forráskódokat, bináris és futtatható állományokat, szövegeket (pl. súgó), képeket, stb. jelentenek. Az állományok előállítása egyben azok függetlenül végrehajtható, önálló tesztjeit is jelentik. Az implementáció feladata még az architektúra, illetve a rendszer, mint egésszel kapcsolatos kérdések megválaszolása, így az iteráció esetén szükséges rendszerintegráció tervezése, az osztottság (distribution) tervezése. Az utolsó munkafolyamat, a teszt (test) során összeállítjuk az iterációkon belüli integrációs tesztek és az iterációk végén végrehajtandó rendszertesztek ütemtervét. Megtervezzük és implementáljuk a teszteket, azaz teszt-esetekként megadjuk, hogy mit kell tesztelnünk, teszteljárásokként megadjuk azok végrehajtási módját, és programokat készítünk, ha lehetséges a tesztek automatizálása. A tesztek végrehajtásával párhuzamosan azok eredményeit szisztematikusan feldolgozzuk, majd hibák vagy hiányosságok esetén újabb tervezési vagy implementációs tevékenységeket hajtunk végre. A felsorolt munkafolyamatok a Unified Process ún. mérnöki elemei, melyek mindegyike összefoglaló néven egy-egy modellt állít elő. A mérnöki elemek mellett léteznek még a fejlesztéssel kevésbé szoros kapcsolatban lévő kiegészítő elemek (pl. a fejlesztés irányítása) is. A fejlesztés folyamatának időbeni és munkafolyamatok alapján történő felbontása egy intenzitási görbe segítségével kapcsolható össze. Az előkészítés fázisában a legnagyobb hangsúly a követelmények rögzítésére helyeződik, a többi tevékenység pedig jóval kisebb mértékben kap szerepet, tesztelés pedig gyakorlatilag nincs is. A későbbi iterációkban, illetve fázisokban ez a hangsúly fokozatosan áthelyeződik a technikaibb jellegű tevékenységekre. Az átadás fázisában már elsősorban tesztelés zajlik, így elemzés, tervezés és implementáció a tesztekre vonatkozóan és azok eredményeitől függően válik szükségessé, míg a követelmények összegyűjtése már nem kap szerepet. A Unified Process az egyes munkafolyamatok (workflow) ábrázolására speciális diagramokat alkalmaz. A diagram alapelemei a tevékenységek, melyek mindegyike egy vagy több produktumot (dokumentumot, kódot, stb.) hoz létre, vagy azokon módosít. A diagramot a tevékenységeket végrehajtó személyek, ún. munkatársak alapján vonalakkal elválasztott sávokra (swimlanes) bontjuk. Minden tevékenység az azért felelős munkatárs mezőjében helyezkedik el, a tevékenységek ajánlott időbeli egymásutániságát, sorrendiségét pedig nyilakkal jelöljük. Fontos megjegyeznünk, hogy a munkafolyamat-diagram a tevékenységeknek mindössze egy logikai sorrendiségét határozza meg, melytől a körülményeknek megfelelően


41/69

eltérhetünk. Nem szükséges tehát követnünk a diagramot, hanem módosíthatunk a sorrendiségen, ha az ugyancsak az eredetivel „ekvivalens” végeredményhez vezet. A munkatárs (worker) általában nem egy konkrét személyt jelöl, hanem egy adott szaktudást, illetve olyan pozíciót, amelyet egy vagy több konkrét személy is betölthet. A fejlesztés folyamán

egyetlen

személy

különböző

pozíciókban,

különböző

„munkatársként”

is

megjelenhet, illetve egyetlen „munkatárs” szerepét általában több konkrét személy tölti be. 4.1.1 A Unified Process jellemzői A Unified Process más, objektumorientált rendszerfejlesztési eljárásokhoz a három legjellemzőbb tulajdonsága alapján hasonlítható. A Unified Process az Objectory örököseként egy ún. használati eset vezérelt (usecase-driven) eljárás, amely azt jelenti, hogy a fejlesztés teljes folyamata során a használati eseteket eszközrendszerét, illetve az azzal kialakított modellt alkalmazzuk a fejlesztés ütemezésére. A használati esetek önmagukban még nem adnak a teljes fejlesztési folyamathoz elegendő információt. A szükséges többletet a Unified Process a rendszer architektúrájaként nevezi meg, mely a rendszernek a fejlesztésben részt vevő összes munkatárs által közösen kialakított vázát, leglényegesebb elemeinek gyűjteményét jelenti. A

Unified

Process

architektúra

központú

(architecture-centric)

eljárás,

mivel

a

munkafolyamatokban nagy hangsúlyt kap a megfelelő architektúra kialakítása. A Unified Process a fejlesztés teljes folyamatát kisebb részekre bontja, melyek önállóan is egy teljes fejlesztési folyamatot jelentenek. Az egyes részeket iterációknak nevezzük, mivel a fejlesztést ismétlődő, iteratív ciklusokban hajtjuk végre. Egy iteráció nem a rendszer egy, a korábbitól független részét állítja elő, hanem a rendszert újabb funkcionalitással bővíti, vagy a korábbi funkcionalitást teszi változatosabbá, gazdagítja. Az iteráció bővítését és módosítását inkrementumnak nevezzük. A Unified Process így egy iteratív és inkrementális (iterative and incremental) fejlesztési módszer. Használati eset vezérelt eljárás A Unified Process célja a fejlesztőknek egy olyan lépéssorozat megadása, mellyel hatékonyan kifejleszthetik és telepíthetik azt a rendszert, mely a felhasználók igényeinek megfelelő. A hatékonyság mérhető a költségek, a minőség és a fejlesztési idő egységeivel. A felhasználók igényeinek teljesítése és annak ellenőrzése azonban több problémába is ütközik. Részben magának a felhasználók igényeinek, a követelményeknek a felderítése is nehéz, az implementáció helyessége, a teljesítés ellenőrzése pedig a tesztelés feladataként jelenik meg. A használati esetek eszközkészlete a gyakorlat által bizonyítottan az egyik legegyszerűbb és legalkalmasabb eszköz a rendszerrel támasztott alapvető igények összegyűjtésére.


42/69

Mindezek mellett az így kialakult modell a teljes fejlesztési folyamat ütemezésére is kiválóan alkalmazható. Az elemzés folyamatában a használati eset modellt vizsgáljuk, abból kiválasztjuk az aktuális iterációban kidolgozandó elemeket, majd abból egy olyan elvi („elemzési”) modellt építünk fel, amely logikailag alkalmas a használati esetek követelményeinek a megvalósítására. Ehhez elkészítjük a használati esetek elemzési szintű megvalósításait, melyek elvi szinten, osztályok közötti üzenetküldésekként „lejátsszák” a feladathoz szükséges interakciókat. A használati esetek, ill. a használati eset megvalósítások kettőse lehetővé teszi azt, hogy az elemzési modell minden egyes eleme esetén pontosan nyomon követhető, hogy milyen céllal került be a rendszerbe. A megvalósítások alapján a használati esetek feladatait az osztályokra vonatkozó követelményekké bontjuk szét. A tervezés munkafolyamata során ugyancsak a használati eseteket vesszük sorra. Ekkor azok elemzési szintű megvalósításait tervezési szintű megvalósításokká írjuk át, melyeket már a kiválasztott konkrét platform és programozási nyelv eszközrendszerével és jelöléseivel adunk meg. A tervezés során így az elemzési elvi modellt konkrét gyakorlati tartalommal töltjük fel. Az implementáció a tervezés leírásának megfelelő forráskódok és egyéb alkotóelemek, ún. komponensek elkészítését jelenti. A használati esetek ekkor segítenek kialakítani a komponensek implementációjának és integrációjának a sorrendjét. Végül, a teszt munkafolyamat során a tesztelők ellenőrzik, hogy a használati esetek által meghatározott funkcionalitás valóban megfelelően és hiányok nélkül implementálásra került. A teszt modell a használati esetek alapján kialakított ún. teszt-eseteket tartalmaz, melyek adott bemeneti adatok és végrehajtási feltételek gyűjteményét, valamint az azokra adott elfogadható válaszokat határozzák meg. Architektúra központú fejlesztés A használati esetek rendkívül

alkalmasak

a

követelmények

összegyűjtésére

és

ábrázolására, valamint a fejlesztés ütemezésére, azonban önmagukban túlságosan „cseppfolyósak”, nem rajzolják meg elég pontosan a készítendő rendszer körvonalait. A rendszer lényegi, működtető alapszerkezetét, a „körvonalakat” a Unified Process a rendszer architektúrájaként nevezi. A rendszer architektúrája annak leglényegesebb elemeit tartalmazza, melyek együttesen a rendszer alapszerkezetét adják meg. Az alapszerkezet a rendszer megértése és kifejlesztése során alapvető fontosságú. A Unified Process szerzői egy házépítés példája alapján magyarázzák el az architektúrát. A házépítés előtt különböző tervrajzokat készítünk, például az építményt megadó rajzot, valamint több más, például a vízvezeték-, fűtés- és elektromos-rendszert

ábrázoló

rajzokat.

Az

egyes

részek

konkrét

megvalósítása

szempontjából a rajzok csak vázlatok, azonban meghatározzák a szükséges alapvető


43/69

felépítést. A különböző munkatársak által igényelt különböző rajzok a teljes „rendszer” más és más nézeteit (view) határozzák meg, mely nézetek együttesen adják meg az architektúrát. Az architekturális leírásra több szempontból is szükségünk van. A napjainkban fejlesztett szoftver-rendszerek általában nagyméretűek, bonyolult környezetben helyezkednek el és rendkívül összetett a belső felépítésük és működésük. Az architektúra a bonyolult teljes rendszer egy áttekintő képét fogalmazza meg, így segíti a rendszer megértését. Az architektúra a fejlesztés felbontására és ütemezésére is alkalmazható. A rendszert általában alrendszerekre bontjuk, melyek egymáshoz adott interfészeken keresztül kapcsolódnak. A felbontást követően meghatározzuk az alrendszerek kifejlesztésének sorrendjét és a fejlesztésért felelős csoportokat. Mivel az architektúra segíti a teljes rendszer áttekintését, ezért arra is kiválóan alkalmazható, hogy az elemek általánosításával több helyen is alkalmazható komponenseket határozzunk meg, melyeket ezután az ún. újrafelhasználással az ismételt fejlesztés költségének a töredékéért beépíthetünk. Ugyancsak az áttekinthetőség miatt a jó architekturális leírás a rendszer későbbi módosításait is megkönnyíti, mivel könnyebben meghatározható, hogy mit és milyen módon kell módosítanunk és az milyen erőforrásokat igényel. A megfelelően kialakított architektúra esetén pedig egy új funkcionalitás bevezetése a rendszer kisebb mértékű változtatásával is végrehajtható. Az architektúra kialakítását a rendszerfejlesztés környezete is nagymértékben befolyásolja, például a következő tényezők: • • • • • • • •

alkalmazott rendszerszoftverek, például operációs rendszerek és adatbázis kezelők, alkalmazott middleware, pl. az osztottság keretrendszere vagy a felhasználói felületek keretrendszere, milyen, már létező külső rendszerekhez kell illeszkedni, milyen külső vagy belső szabványokat alkalmazunk, általános szerepű nem-funkcionális követelmények, RUP áttekintés osztottság architekturális követelményei, pl. kliens-szerver architektúra alkalmazása. A Unified Process külön definiálja az alaparchitekúra (architecture baseline) fogalmát, mely a teljes rendszer egy önállóan is működő, erősen egyszerűsített változata. A későbbi iterációk ezen alaparchitektúra alapján, illetve az köré építkeznek Iteratív és inkrementális eljárás A feladatok összetettsége miatt minden szoftver-fejlesztési eljárás során célszerű egyértelműen megfogalmazni a fejlesztés mérföldköveit (milestones), hogy világosan látható legyen a mérföldkövek közötti fázis (phase) során elérendő cél. A fázisok nagyobb egységeit


44/69

ugyancsak célszerű további kisebb lépésekre bontani, mely lépések a Unified Process esetén az inkrementumokat megvalósító iterációs lépések lesznek. Iteratív és inkrementális fejlesztés esetén a teljes fejlesztési folyamat nem vízesésszerűen, egyetlen nagy egységben történik. Ehelyett minden belső kis fejlesztési ciklus esetén először „szervezünk egy keveset, elemzünk, tervezünk, implementálunk egy keveset, majd integrálunk és tesztelünk egy keveset” — a Unified Process szerzőinek már szlogenné vált receptje szerint. Az iterációs ciklusokban a rendszer egyre bővülő részeit fejlesztjük ki. A „bővítményeknek”, azaz az inkrementumoknak a rendszerhez való kapcsolása így nem a teljes fejlesztés végén, egyetlen nagy lépésben történik, hanem azt a fejlesztés során folyamatosan kell végrehajtani. Az

iteratív

és

inkrementális

rendszerfejlesztési

eljárás

legfontosabb

előnyeit

a

következőkben foglalhatjuk össze: • • • •

a fejlesztés kritikus és lényeges kockázatai hamarabb azonosíthatók, a megfelelő architektúra könnyebben kialakítható, egíti a változó követelményeknek megfelelően, könnyebben módosítható keretrendszer kialakítását • a munkatársak hatékonyabban vehetnek részt a fejlesztésben. Fázisok A fejlesztést az idő alapján a fázisok nagyobb egységeire bontjuk. Minden fázis a fejlesztés egy-egy jól meghatározott mérföldkövét jelenti, azaz olyan pontot, ahol egy célt elértünk, illetve ahol kritikus döntéseket kell meghozni. Minden fázis végén megvizsgáljuk az elért eredményeket és döntünk a fejlesztés folytatásról. Minden fázis közbülső iterációkra bontható, mely egy-egy teljes fejlesztést jelent, amelyek mind végrehajtható alkalmazást, a végső, teljes rendszer egyre bővülő részeit eredményezik. Az előkészítés (inception) elsősorban üzleti szempontból írja le a fejlesztést és meghatározza az alkalmazás határait. Az üzleti szempont röviden a következőket jelenti: • sikertényezők meghatározása • kockázati tényezők felmérése • erőforrás-becslés • projektterv: a mérföldkövek dátumainak meghatározása A fázis végén meghatározzuk az egyes iterációs ciklusok célját és döntünk a folytatásról A kidolgozás (elaboration) során a problémát elsősorban szakterületi szempontból elemezzük. Ehhez a következő feladatokat kell végrehajtanunk: • megbízható architektúrát alakítunk ki • meghatározzuk a projekt-tervet • megszüntetjük a legkritikusabb kockázati tényezőket


45/69

Az architektúrára vonatkozó helyes döntéseket csak a teljes rendszer megismerése után hozhatunk, ezért szükséges, hogy a használati esetek döntő részét specifikáljuk, valamint, hogy meghatározzuk a nem-funkcionális követelményeket. Ezután a megoldási módokat ellenőrizzük egy olyan rendszer implementálásával, amely bemutatja a kiválasztott architektúra működését és végrehajtja a jellemző használati eseteket. A fázis végén kiválasztottuk az architektúrát és megszüntetettük a főbb kockázati tényezőket. A mérföldkőnél itt is elemezzük az elért eredményeket és döntünk a folytatásról. A megvalósítás (construction) során a teljes rendszert iteratív és inkrementális módon kifejlesztjük. Ehhez: • specifikáljuk az elmaradt használati eseteket • a tervezésre helyezzük a hangsúlyt • kiegészítjük az implementációt • teszteljük az elkészített alkalmazást A fázis végén már működőképes szoftvert állítunk elő, melyről döntenünk kell, hogy az kibocsátható-e a felhasználóknak. Az átadás (transition) lezáró fázisa során az alkalmazást átadjuk a felhasználóknak. • Ez a fázis tipikusan az alkalmazás béta-tesztjével kezdődik. • A rendszer hangolása miatt szükség lehet kiegészítő fejlesztésekre. • A megjelenő hibákat ki kell küszöbölni. • A még hiányzó részeket ki kell fejleszteni. A fázis végén dönteni kell, hogy elértük-e a fejlesztés során kitűzött célokat, illetve, hogy indítanunk kell-e újabb fejlesztési ciklust. Ugyancsak célszerű, hogy a projekt tapasztalatait elemezve vizsgáljuk meg azt, hogy miként módosíthatunk a fejlesztési módszerünkön.

4.1.2 Összefoglalás A Unified Process a rendszerfejlesztés folyamatát két dimenzióval írja le. Az egyik dimenzió a fejlesztés időbeliségét, dinamikáját követi, mely mentén négy fázist különböztet meg. Az Előkészítés fázisában a rendszer eredeti ötletét olyan részletes elképzeléssé dolgozzuk át, mely alapján a fejlesztés tervezhető lesz, a költségei pedig megbecsülhetők. A Kidolgozás fázisában a használati módokat, a „használati eseteket” részleteiben is kidolgozzuk, valamint össze kell állítanunk egy stabil alaparchitektúrát. A Megvalósítás során a teljes rendszert kifejlesztjük, az Átadás pedig elsősorban a rendszer bétaváltozatának a kipróbálását jelenti. A statikus dimenzió az eljárás elemeit határozza meg, az elkészítendő dokumentumokat (diagramokat, forráskódokat). A Unified Process használati eset vezérelt, architektúra központú, valamint iteratív és inkrementális fejlesztési módszer.


46/69

5

A szoftver folyamat érettsége

5.1 Szoftverfejlesztési képesség-érettség A képességérettség modellt (CMM~Capability Maturity Model) az 1980-as évek végén dolgozták ki az USA Védelmi Minisztériumának megbízásából szoftverfejlesztő szervezetek megbízhatóságának felmérésére és javítására. Ez az egyértelmûen folyamatjav ítás szemléletû megközelítés azóta nemcsak a szoftverfejlesztés, hanem a rendszerfejlesztés, az integrált termék. és folyamatfejlesztés és még néhány más terület USA-ban és máshol legszélesebb körben elfogadott alapmodelljévé vált. Befolyást gyakorolt többek között a magyar szabványként is megjelent ISO/IEC 12207:1995 szoftveréletciklus folyamatokat leíró szabványra, valamint az ISO/IEC 15504(SPICE~Software Process Improvement and Capability dEtermination) szoftverfolyamat értékelési szabványtervezetre. A CMM mind a szoftver-, mind a rendszerfejlesztésre alkalmazható integrált verziója a CMMI (Capability Maturity Model Integration) a 2000. év második felében jelent meg. A CMMI egy olyan keret, amelyből kiindulva különböző szervezetek számára lehet modellt szabni.

5.2 Érettségi modellek Az már az 1980-as években világossá vált, hogy vannak a technológiákban érettebb és kevésbé érettebb folyamatok. Az érettség elemzésénél a szervezetet bizonyos, előre meghatározott kritériumok alapján vizsgálják, és ezek alapján a szervezetet besorolják egy bizonyos érettségi szintre. A szoftver folyamat érettsége a CMM szerint annak mértéke, hogy egy olyamat mennyire pontosan meghatározott, vezérelt, mért, ellenőrzött és hatékony. A szoftverfolyamat érettsége megmutatja, hogy a folyamat képes-e jó minőségű terméket előállítani a költségés időkeretek betartásával. Ennek értelmében tehát az érett szoftver folyamat meghatározott (definiált), vezérelt, mért, ellenőrzött, hatékony és javulásra képes. A

rendelkezésre

álló

érettségi

modelleknek

meghatározott

struktúrája

van,

a

szoftverfejlesztés bizonyos elemeire koncentrálnak. Ellenőrzési modellek jöttek létre, amelyek auditálhatóságot biztosítanak (ilyenek pl. a Bootstrap, a CMMI módszertanok.) 5.2.1

Lépcsős modellek

A lépcsős modellek a teljes szervezetet vizsgálják, úgy tekintik, hogy a szervezetben egyetlen folyamat van, amelynek bizonyos jellemzői vannak. Ez maga a szoftverfejlesztési folyamat, amely a következőket foglalja magába:


47/69

• A szoftverfejlesztésben résztvevő emberek • A szoftverfejlesztésben alkalmazott technológiát • A szoftverfejlesztésben alkalmazott módszereket • A szoftverfejlesztésben alkalmazott eszközöket. 1982-ben az US Department of Defense (DoD) kezdett a problémakörrel foglalkozni, ennek eredményeképpen jött létre a Carnegie Mellon Egyetemen a Software Engineering Institute (SEI) 1984 decemberében. A szoftver folyamatjavítás témakörben az első projekt 1986-ban indult. A CMM modellt Watts Humphrey vezetésével 1989-1991 között dolgozták ki. A modell első változata a DoD támogatásával jött létre, a megjelenési formája egy kérdőív volt, 110 kérdéssel, és lehetővé tette a szoftvergyártó cégek elhelyezését egy 5-ös skálán. Összefoglalóan a CMM eljárások története látható a következő ábrán.

History of CMMs CMM for Software v1.1 (1993)

Software CMM v2, draft C (1997)

INCOSE SECAM (1996)

Systems Engineering CMM v1.1 (1995)

EIA 731 SECM (1998)

Integrated Product Development CMM

(1997)

v1.02 (2000) v1.1 (2002) CMMI for Acquisition v1.2 (2007)

5.2.2

CMMI for Development v1.2 (2006)

CMMI for Services v1.2 (2007)

Folytonos modellek (continuous models)

A folytonos modellek az egyes folyamatokra (és nem a teljes szervezetre) állapítanak meg érettségi szinteket előre meghatározott jellemzők alapján. A modell alkalmazója maga döntheti el, hogy mely folyamat érettségét szeretné vizsgálni. 5.2.3

Kombinált modellek

A kombinált, integrált modellek ötvözik a kétféle modellt, kiválasztják a gyakorlatban leghasználhatóbbnak bizonyult elemeket és ezeket alkalmazzák.

5.3 A CMM érettségi szintjei A CMM modell szintjei a következők:


48/69

• • • • •

1. Kezdeti (initial) 2. Ismételhető (repeatable) 3. Meghatározott (defined) 4. Menedzselt (managed) 5. Optimalizált (optimized)

Az érettségi szintek mérésére egy kérdőíves felmérés szolgál, amelynek elemzésével alakul ki a szervezet egészére vonatkozó mérőszám. A felmérés lépései: • Kérdőívek kitöltése • Megbeszélések • Jelentés elkészítése • Regisztráció a CMM adatbázisba A felmérés eredménye egy egész szám (érettségi szint az 1-5 skálán, indoklással.) Ez a szervezet egészére vonatkozó érettséget mutat. 5.3.1

Kezdeti szint

Az 1. kezdeti szintre a következők jellemzők: • A tervek és módszerek felrúgása • A költség- és időkeretek túllépése (a termék természetesen ettől még működhet) • A fejlesztés sikere az egyes személyek hozzáértésétől és „hősiességétől”, áldozatvállalásától függ • A folyamat ebben a formájában nem megismételhető. 5.3.2

Ismételhető szint

A 2. ismételhető szinten jelentős előrelépés található a kezdeti szinthez képest: • • • •

Egyes projektek folyamatokat alkalmaznak A folyamatok projektenként változhatnak A szervezeti szintű, politikai jellegű projektvezetés a jellemző A projektekben − Reális vállalások történnek − A projektet tervezik és követik költség, idő és funkcionalitás szempontjából − Vannak a projektre vonatkozó szabványok és követik őket − A termékeket ellenőrzik minőségi szempontból − A beszállítókkal jól működő kapcsolat van A következő eljárások már rendelkezésre állnak: • • • • • •

Szükséglet menedzsment Szoftver projekttervezés Szoftver projektkövetés Szoftver alvállalkozó menedzsment Szoftver minőségbiztosítás Szoftver konfigurációmenedzsment


49/69

5.3.3

Meghatározott szint

A 3. meghatározott szinten kidolgozott, vállalati szinten szabványos szoftver folyamat létezik, amely a legjobb iparági gyakorlatokon alapul (best practice). A szoftver folyamathoz szoftver menedzsment és szoftver fejlesztési folyamatok tartoznak és egy projekt a szabvány vállalati szoftver folyamat testre szabott változata alapján működik. A következő eljárások (kiegészítve az előző szint eljárásait) rendelkezésre állnak: • • • • • • •

5.3.4

Szervezeti projekt fókusz Szervezeti eljárás definíciók Oktatási program Integrált szoftver menedzsment Szoftvergyártási eljárások Csoportok közötti koordináció Peer review eljárások

Menedzselt szint

A 4. menedzselt szinten a következő elemek állnak rendelkezésre • • • •

Mennyiségi folyamatmenedzsment Szoftver minőség menedzsment Statisztikai módszerek alkalmazása a folyamatokban A folyamatváltozások vizsgálata rendszeresen megtörténik a változások sajátos okaira koncentrálva A következő eljárások már rendelkezésre állnak kiegészítve az előző szint eljárásait: • Kvantitatív folyamat menedzsment • Szoftver minőségirányítás 5.3.5

Optimalizált szint

Az 5. optimalizált szinten a következő elemek lépnek be: • • • •

Hibamegelőzés Technológia-változás — menedzsment Folyamatváltozás — menedzsment Az esetleges gyenge teljesítmények valódi okainak meghatározása és megszüntetése • A szoftverfolyamat folytonos javítása (continuous improvement) A következő eljárások már rendelkezésre állnak kiegészítve az előző szint eljárásait: • Hibamegelőzés • Technológiai változásmenedzsment • Folyamat változásmenedzsment


50/69

5.4 A CMMI modell A CMMI modell kidolgozásának célja az volt, hogy a korábban a szoftverfejlesztésben, rendszerfejlesztésben

és

termékfejlesztésben

leggyakrabban

alkalmazott

modellek,

megközelítések egyetlen modellé álljanak össze, amelyet bármely, szoftverfejlesztéssel (is) foglalkozó szervezet alkalmazhat a teljes szervezet érettségének és/vagy folyamatai képességének növelésére. A CMMI modell a következő szabványokat integrálja • Capability Maturity Model for Software (SW-CMM) v2.0 draft C • Electronic Industries Alliance Interim Standard (EIA/IS) 731, Systems Engineering Capability Model (SECM) • Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98 • A modell kompatibilis az ISO/IEC 15504 Technical Report for Software Process Assessment-ben leírt modellel, vagyis a SPICE modellel is. Ennek megfelelően tehát a CMMI modell a következő területeken alkalmazható:

A

• Szoftverfejlesztés • Rendszerszervezés- és fejlesztés • Integrált termék- és folyamatfejlesztés szoftverfejlesztés kötelezően választandó

terület,

a

rendszerfejlesztésben

a

szoftverfejlesztés modelljét használhatjuk a követelmények megfeleltetésével. A SEI 2006 augusztus 25-én adta ki a CMMI v 1.2 változatát. A változtatások röviden a következő területeket érintik: • A CMMI modell komplexitásának és méretének csökkentése • A modell által lefedett területek növelése • A modell auditálásával kapcsolatos bizalom erősítése. 5.4.1 A CMMI folyamat dimenziója Folyamat menedzselés • Szervezeti folyamat-központúság • Szervezeti folyamat-meghatározás • Szervezeti képzés • Szervezeti folyamat-véghezvitel • Szervezeti innováció és terítés Projekt menedzselés • • • • • • •

Projekt tervezés Projekt követés és ellenőrzés Beszállítói megállapodások menedzselése Integrált projekt menedzselés Integrált csoportkialakítás Kockázat-menedzselés Kvantitatív projekt menedzselés


51/69

Támogatás • Konfiguráció menedzselés • Folyamat és termék minőségbiztosítás • Mérés és elemzés • Döntéselemzés és megoldás • Oksági elemzés és megoldás • Szervezeti környezet és integráció Technológia • • • • • •

Követelmény menedzselés Követelmény kidolgozás Műszaki megoldás Termék integráció Ellenőrzés Érvényesítés

A SPICE CMMI képesség dimenziója, a CMMI szintek:

5.4.2

Egy példa CMMI folyamatra

A példa projekttervezés. A következő lényeges elemekre kell építenünk a folyamatokat: Specific Goals (Specifikus célok)

• SG 1Establish Estimates (Becslések meghatározása) − Meg kell határozni és karban kell tartani. a projekt tervezési paraméterek becsléseit. • SG 2Develop a Project Plan (Projektterv kidolgozása)


52/69

− Létre kell hozni és karban kell tartani egy projekttervet, amely a projekt vezetésének alapjául szolgál. • SG 3Obtain Commitment to the Plan (Az emberek váljanak elkötelezetté a projektterv iránt) − El kell érni, és fenn kall tartani a projektterv iránti elkötelezettséget. Generic Goals (Általánosított célok) • GG 1 Achieve Specific Goals (A specifikus célok elérése) − A folyamat támogatja és lehetővé teszi a folyamatterület specifikus céljainak megvalósulását azáltal, hogy azonosítható bemenő termékeket azonosítható kimenő termékekké alakít. • GG 2Institutionalize a Managed Process (Menedzselt folyamat intézményesíitése) • GG 3Institutionalize a Defined Process (Meghatározott folyamat intézményesíitése) • GG 4Institutionalize a Quantitatively Managed Process (Számszerű adatokra alapozott menedzselési folyamat intézményesíitése) • GG 5Institutionalize an Optimizing Process (Optimalizáló folyamat intézményesíitése) Specific Goals (Specifikus célok) + Specific Practices (Specifikus módszerek) SG 1 Establish Estimates (Becslések meghatározása) • SP 1.1-1 Estimate the Scope of the Project (A projekt hatásterületének felmérése) • SP 1.2-1 Establish Estimates of Project Attributes (A projekt jellemzőinek becslése) • SP 1.3-1 Define Project Life Cycle (A projekt életciklusának meghatározása) • SP 1.4-1 Determine Estimates of Effort and Cost (Erőforrás és költség becslések) SG 2 Develop a Project Plan (Projektterv kidolgozása) • • • • •

SP 2.1-1 Establish the Budget and Schedule (Költségvetés és ütemezés) SP 2.2-1 Identify Project Risks (Kockázatazonosítás) SP 2.3-1 Plan for Data Management (Adatkezelési terv) SP 2.4-1 Plan for Project Resources (Erőforrásterv) SP 2.5-1 Plan for Needed Knowledge and Skills (Tudás és képességek tervezése) • SP 2.6-1 Plan Stakeholder Involvement (Érdekelt felek bevonásának terve) • SP 2.7-1 Establish the Project Plan (Projektterv) SG 3 Obtain Commitment to the Plan (Az emberek váljanak elkötelezetté a projektterv iránt) • SP 3.1-1 Review Subordinate Plans (Alárendelt tervek áttekintése)


53/69

• SP 3.2-1 Reconcile Work and Resource Levels (A feladatok és erőforrások összeegyeztetése) • SP 3.3-1 Obtain Plan Commitment (A terv iránti elkötelezettség biztosítása) Generic Goals (Általánosított célok) + Generic Practices (Általánosított módszerek) GG 2 Institutionalize a Managed Process (Menedzselt folyamat intézményesíitése) • • • • • • •

GP 2.1 Establish an Organizational Policy (Szervezeti politika) GP 2.2 Plan the Process (Folyamatterv) GP 2.3 Provide Resources (Erőforrások biztosítása) GP 2.4 Assign Responsibility (Felelősségi körök kijelölése) GP 2.5 Train People (Képzés) GP 2.6 Manage Configurations (Konfiguráció-kezelés) GP 2.7 Identify and Involve Relevant Stakeholders (Érdekelt felek azonosítása és bevonása) • GP 2.8 Monitor and Control the Process (Folyamat követése és ellenőrzése) • GP 2.9 Objectively Evaluate Adherence (Megfelelőség objektív értékelése) • GP 2.10 Review Status with Higher-Level Management (Helyzet-szemle a felső vezetéssel) GG 3 Institutionalize a Defined Process (Meghatározott folyamat intézményesítése) • GP 3.1 Establish a Defined Process (Meghatározott folyamat létrehozása) • GP 3.2 Collect Improvement Information (Javítási információk gyűjtése) GG 4 Institutionalize a Quantitatively Managed Process (Számszerű adatokra alapozott menedzselési folyamat intézményesíitése) • GP 4.1 Establish Quantitative Objectives for the Process (Mennyiségi célok meghatározása) • GP 4.2 Stabilize Subprocess Performance (Részfolyamatok végrehajtásának stabilizálása) GG 5 Institutionalize an Optimizing Process (Optimalizáló folyamat intézményesíitése) • GP 5.1 Ensure Continuous Process Improvement (Folytonos folyamatjavítás biztosítása) • GP 5.2 Correct Root Causes of Problems (Problémák eredendő okainak kiküszöbölése)

5.5 SEI +SAFE, V1.2, A Safety Extension to CMMI-DEV, V1.2 A CMMI szabványhoz tartozó kiegészítést a Defence Material Organisation (Australian Department of Defence) készítette. A kiegészítés lényegében két újabb folyamatot ad hozzá az eredeti szabványhoz, ezzel egy jól kezelhető módszert ad szervezetek biztonság kritikus alkalmazásfejlesztési képességének elemzéséhez.


54/69

A fejlesztés előzménye az volt, hogy a Defence Material Organisation (Australian Department of Defence) megfigyelte, hogy az eredeti szabvány nem fedi le teljesen a biztonsági szoftvermérnöki tevékenység elemeit és folyamatait. A biztonság-kritikus alkalmazások

fejlesztése

speciális

folyamatokat,

technikákat,

képességeket

és

tapasztalatokat igényel egy szervezeten belül. A CMMI megadja ezen folyamatok és képességek elemzéséhez az alapokat, de konkrét eljárásokat és mérőszámokat nem határoz meg. A +SAFE alapvető lényege az, hogy azonosítja a termék és szolgáltatásfejlesztők számára a biztonsággal kapcsolatos erősségeket és gyengeségeket, lehetővé teszi a gyengeségek felmérését még az elemzési szakaszokban egy fejlesztés során. Ez a kiegészítés nem hivatkozik más információbiztonsági szabványokat, de átfedésben van a CMMI-vel és más információbiztonsági szabványokkal is. A szabványos kiegészítés szerkezete a következő:

CMMI PA Category

Safety Process Area

Specific Goals

Project Management

Safety Management

SG1 Develop Safety Plans SG2 Monitor Safety Incidents SG3 Manage Safety-Related Suppliers

Engineering

Safety Engineering

SG1 Identify Hazards, Accidents, and Sources of Hazards SG2 Analyze Hazards and Perform Risk Assessments SG3 Define and Maintain Safety Requirements SG4 Design for Safety SG5 Support Safety Acceptance

A +SAFE a következő módon épül be a CMMI-ba:


55/69

5.5.1 A +SAFE és a CMMI-DEV kapcsolata A +SAFE kiegészítő folyamat területeket (Process Area) ad a CMMI modellhez. A +SAFE process areak közvetlenül beépülhetnek az eredeti CMMI process areak közé, mégpedig a Proejct Management és az Engineering (Szoftver-mérnöki) folyamatok közé. A Safety Management és a Safety Engineering területek így közvetlenül elemzésre kerülhetnek a kiegészített CMMI-DEV eljárásban. 5.5.2 A +SAFE és más információbiztonsági szabványok A +SAFE nem igényli egyetlen információbiztonsági szabvány alkalmazását sem, ugyanakkor igyekszik konzisztens lenni a következő szabványokkal és szabványos eljárásokkal: • Australian Defence Standard, Safety Engineering in the Procurement of Defence Systems, • the principles of other contemporary safety standards − IEC’s Safety of Machinery—Functional Safety of Safety-Related Electrical, Electronic and Pro-grammable Electronic Control Systems;


56/69

− U.S. military standard, System Safety Pro-gram Requirements; t − he U.K. Defence Standard, Safety Management Requirements for Defence Systems, Part 1, Issues 2 and 3; and domain-specific safety standards wherever feasible) [ADoD 1998, CEI/IEC 2005, UKMoD 1997, UKMoD 2004, USDoD 1993]. A +SAFE által használt jelölések és definíciók a következők:

Acronym or Glossary Term +SAFE accident acceptably safe

appropriate

CMMI CMMI-DEV CMMI +SAFE DMO harm

hazard


Meaning

The safety extension to CMMI. An event or sequence of events that leads to harm, also known as a “mishap” or “hazardous event.” The maximum level of risk of a particular technical process or condition that is regarded as acceptable in the circumstances in question. When applied to a method or technique used in safety-related engineering, “appropriate” is intended to mean that there is consensus that the method or technique is suitable for the relevant safety target. Some standards such as Def (Aust) 5679 and IEC 61508 recommend appropriate meth-ods and techniques. There is currently little quantitative evi-dence that the methods and techniques recommended are actually effective in achieving the associated safety targets. Hence +SAFE avoids the word “effective,” which is, how-ever, used in CMMI. Capability Maturity Model Integration Capability Maturity Model Integration for Development CMMI with the safety extension. Defence Materiel Organisation, Australian Department of Defence. The consequence when a safety risk matures. Types of harm include harm to people (e.g., fatalities and serious and/or minor injuries), damage to property or the environment, loss of product capability, damage to or loss of data, or economic loss. A situation with the potential to lead to an accident.

57/69

high-level safety argument LOT

A safety argument for a major function or component of a safety-critical product.

MOTS OTS safety

military off the shelf off the shelf An acceptable level of risk. Absolute safety (i.e., zero risk) is not generally achievable. Therefore, we define safety in terms of the level of risk that is deemed acceptable.

safety argument

The statement of why a particular characteristic of a product or product component meets safety requirements and safety targets. The statement is usually structured as an argument and its supporting evidence. Also known as “safety case argument.”

safety case

Depending on the domain, the safety case is either: (1) the complete body of evidence that proves an item was designed and integrated correctly to approved standards by competent people in accordance with approved procedures with suffi-cient mitigation, and tested sufficiently to justify it being safe; or (2) a well-reasoned summary document detailing what the original safety program aims were versus what was actually achieved, and a risk analysis (with recommenda-tions) of the differences. Also known as a system safety assessment (SSA) and assur-ance case. See safety argument.

safety case argu-ment safety criteria

level of trust. A measure of the level of confidence or trust that one wishes to have that the product meets a given prod-uct safety requirement.

The limits of acceptable risk associated with a hazard. These limits may be defined (externally) as imposed safety targets, or developed from analysis or development policy.

safety critical

A product or product component that, based on a safety as-sessment, has safety requirements that must be satisfied for the product or product component to be accepted for service.

safety function

A functional requirement that is needed to ensure the safety of the product. Also known as safety functional requirement.


58/69

safety functional requirement safety incident

safety lifecycle safety related safety risk

5.5.3

See safety function.

An event in which injury or damage could have occurred and either: (1) raises concern about the safety of any person, product, mission, or procedure; (2) raises the requirement for a modification or change to procedures or products as a re-sult of the event, or (3) highlights a lesson to be learned from the event. The project or product lifecycle in which safety processes are performed. Products, items, or processes used to implement a function or component of safety. When applied to a situation, the (safety) risk presented is a combination of the likelihood and consequence (i.e., severity of any resulting harm).

safety principles

Management and engineering principles for developing and operating systems and product components so that they are most likely to meet safety requirements.

safety requirement

Any requirement that is needed to ensure the safety of the product. These requirements include safety functional re-quirements and their associated safety targets.

SCAMPI

Standard CMMI Appraisal Method for Process Improve-ment.

SEI (safety) target

Software Engineering Institute. A qualitative or quantitative target associated with a safety requirement. A safety target is intended to express how safe an implementation of the safety requirement must be.

A két Process Area rövid leírása

Safety Management A Safety Management célja az, hogy a biztonsági tevékenységek megtervezésre kerüljenek, a biztonsági tevékenységek eredményei és teljesítései monitorozásra kerüljenek a tervnek megfelelően és a tervtől való eltérések korrekciója megtörténjen. A Safety Management Process Area tartalma: • Biztonsági szabályok, kritériumok és célok kitűzése a biztonsági követelmények biztosítására • Tervek implementálása és a biztonsági incidensek figyelése és a tervekkel összhangban álló kezelése • Megállapodások elkészítése és megkötése a leendő felhasználókkal biztonság-alapú termékek és szolgáltatások forgalmazására.


59/69

Safety Engineering A Safety Engineering célja az, hogy a biztonság beépüljön a szoftvermérnöki folyamat minden fázisába. A Safety Engineering folyamat tartalma:

A

• Kockázatok, támadások és kockázati források azonosítása és azon típusok analízise, amelyek biztonsági kockázatokat okozhatnak • Biztonsági eljárások fejlesztése • Biztonsági eljárások és politikák kidolgozása, amelyek a projekt életciklusában végig jelen vannak • Audit folyamat kidolgozása a biztonsági elemek folyamatos vizsgálatára. biztonsági szoftvermérnöki folyamat integrálása egyéb folyamatokkal

(követelményelemzés, technikai megoldás, integrálás, verifikáció) lehetővé teszi, hogy a követelményspecifikációval és technikai megoldással kapcsolatos biztonsági aspektusok a projekt életciklus megfelelő pontján épülhessenek fel és azok megfelelő prioritást kapjanak.


60/69

6

Fogalmak jegyzéke

Adat A tények, az elképzelések nem értelmezett, de értelmezhetô közlési formája. Adatállomány Valamely informatikai rendszerben lévô adatok logikai összefogása, amelyet egy névvel jelölnek. Ezen a néven keresztül férhetünk hozzá a tartalmazott adatokhoz. Adatátvitel Adatok szállítása összeköttetéseken, összekötô utakon (például számítógépek között). Adatbiztonság Az adatok jogosulatlan megszerzése, módosítása és tönkretétele elleni műszaki és szervezési intézkedések és eljárások együttes rendszere. Adatfeldolgozás Az adatok gyűjtése, rendszerezése, törlése, archiválása. Adatvédelem Az adatok kezelésével kapcsolatos törvényi szintű jogi szabályozás formája, amely az adatok valamilyen szintű, elôre meghatározott csoportjára vonatkozó adatkezelés során érintett személyek jogi védelmére és a kezelés során felmerülô eljárások jogszerűségeire vonatkozik. Alapfenyegetettség A

fenyegetô

tényezôk

olyan

csoportosítása,

amely

a

biztonsági

alapfunkciók

valamelyikének kiesését okozza. Nevezetesen: • mûködôképesség elvesztése, • a hitelesség elvesztése, • a bizalmasság elvesztése, • a sértetlenség elvesztése és • a rendelkezésre állás elvesztése. Alkalmazói program (alkalmazói szoftver) Olyan program, amelyet az alkalmazó saját speciális céljai érdekében vezet be és amely a hardver és az üzemi rendszer funkcióit használja. Bizalmasság Az információk vagy adatok esetében a bizalmasság azt jelenti, hogy azokhoz csak az arra jogosítottak és csak az elôírt módokon férhetnek hozzá, és nem fordulhat elô úgynevezett jogosulatlan információ szerzés. Ez vonatkozhat programokra, mint


61/69

szélesebb értelemben vett információkra is (például ha valamely eljárás elôírásait egy programmal írjuk le és azt titokban kívánjuk tartani). Biztonság Az információ és informatikai rendszerekben olyan elôírások és szabványok betartását jelenti, amelyek a rendszer működôképességét, az információk rendelkezésre állását, sértetlenségét bizalmasságát és hitelességét erôsítik. Biztonsági igény Abban az esetben áll fenn, ha egy vagy akár több kockázat elfogadhatatlanul magas és ezért valamit az informatikai rendszer védelme érdekében tenni kell. Biztonsági koncepció Adott

szervezet

olyan

intézkedési

terve,

amelynek

végrehajtása

a

szervezet

tevékenységének jelentôségével és a tevékenység kiesésének kockázatával összefüggô biztonságos működési feltételeket teremti meg. Biztonsági követelmények A kockázatelemzés eredményeként megállapított, elfogadhatatlanul magas kockázattal rendelkezô fenyegetô tényezôk ellen irányuló biztonsági szükségletek együttese. Biztonsági mechanizmus Eljárási módszer vagy megoldási elv, ami azt a célt szolgálja, hogy egy vagy több biztonsági követelményt teljesítsen. Így azután a biztonsági mechanizmusok az intézkedések részét képezik, ám egyben megvalósításukat is érintik. Elérhetôség Az információ-feldolgozás során valamely informatikai alkalmazás szolgáltatásai az adott helyen és az adott idôben igénybe vehetôk. Érték Az információk és feldolgozásuk értéke abból vezethetô le, hogy azok milyen jelentôséggel rendelkeznek a felhasználó által támasztott követelmények kielégítése szempontjából. Az informatikai rendszerelemek értéke pedig azon információk és feldolgozásuk értékébôl származtatható,

amelyek

az

adott

rendszerelem

igénybevételével

megvalósuló

eljárásokban részt vesznek. Felhasználó Az a személy vagy szervezet, aki, (amely) egy vagy több informatikai rendszert használ feladatai megoldásához. Funkció


62/69

Az a lehetôség, amelyet valamely informatikai rendszer kínál, hogy egy meghatározott feladatot valamely informatikai alkalmazás keretében megoldjunk. Hardver Az informatikai rendszer eszközeit, fizikai elemeit alkotó részei. Hálózat Két vagy több számítógép vagy általánosabban informatikai rendszerek összekapcsolása, amely informatikai rendszerek legkülönbözôbb komponensei között adatcserét tesz lehetôvé. Hozzáférés Olyan eljárás, amely valamely informatikai rendszer használója számára elérhetôvé tesz a rendszerben adatokként tárolt információkat. Ez az eljárás bekövetkezhet például névmegadáson keresztül valamely adatszerűségre nézve, s lehetôvé tehet olvasást, írást vagy kifejtést. Informatika A számítógépes információrendszerek tudománya, amely elméletet, szemléletet és módszertant ad a számítógépes információrendszerek tervezéséhez, fejlesztéséhez, szervezéséhez és működtetéséhez. Informatika-alkalmazás Informatika alkalmazó A kézikönyv értelmezésében informatikai alkalmazók lehetnek mind a felhasználók, mind az üzemeltetôk. A felhasználók és az üzemeltetôk az informatikai rendszereket eltérô módon szemlélik, amelyet a következô ábra jellemez: Informatikai biztonság Olyan elôírások, szabványok betartásának eredménye, amelyek az információk elérhetôségét, sérthetetlenségét és bizalmasságát érintik és amelyeket az informatikai rendszerekben vagy komponenseikben, valamint az informatikai rendszerek vagy komponenseik alkalmazása során biztonsági megelôzô intézkedésekkel lehet elérni. A kézikönyv központi fogalma az "informatikai biztonság", amely az ajánlott eljárás tekintetében a következôképpen definiálható: Informatikai biztonság alatt valamely informatikai rendszer azon állapota értendô, amelyben a kockázatokat, amelyek ezen informatikai rendszer bevezetésekor a fenyegetô tényezôk

alapján

adottak,

elfogadható

intézkedésekkel

elviselhetô

mértékűre

csökkentettük.


63/69

Informatikai rendszer A hardverek és szoftverek olyan kombinációjából álló rendszer , amit az adat- illetve információ-feldolgozás különbözô feladatainak teljesítésére alkalmazunk. Az informatikai rendszerek különleges tulajdonsága a szabad programozhatóság. Az informatikai rendszerek közé soroljuk tipikusan a "célszámítógépeket" és az "általános célú számítógépeket". Informatikai rendszerelem Az informatikai rendszer olyan jól elkülöníthetô egysége, amely annak bevezetéséhez/ kiépítéséhez szükséges és amelyet a fenyegetô tényezôk érintenek. Informatikai rendszerelemzés Olyan vizsgálat, amelyet valamely informatikai rendszer beszerzése és bevezetése elôtt valósítanak meg, hogy a vele szemben támasztott követelményeket rögzítsék. Alapja az informatikai rendszer bevezetésének célja, valamint a bevezetés környezete. Informatikai szolgáltatás Valamely informatika-alkalmazás külön is definiált része, mint például egy zárt munkafolyamat, amelyet informatikai rendszerrel támogatnak. Információ Jelentéssel bíró szimbólumok összessége, amelyek jelentést hordozó adatokat tartalmaznak és olyan új ismeretet szolgáltatnak a megismerô számára, hogy ezáltal annak valamilyen bizonytalanságát megszüntetik és célirányos cselekvését kiváltják. Az információ általános értelemben a valóság folyamatairól és dologi viszonyairól szóló felvilágosítás. Ebbôl következôen értelmezése kapcsolatfüggô. Információ-feldolgozás Az adat-feldolgozás általános szinonimája, amely alatt értjük az információk *

begyûjtését,

*

feltérképezését/feltárását,

*

használatát,

*

tárolását,

*

továbbítását,

*

programvezérelt feldolgozását (szoros értelemben) és

*

ábrázolását.

Információrendszer Információk meghatározott célú, módszeres gyűjtésére, tárolására, feldolgozására (bevitelére, módosítására, rendszerezésére, aggregálására) továbbítására, fogadására,


64/69

megjelenítésére, megsemmisítésére stb. alkalmas rendszer. Ha ez a rendszer számítógéppel támogatott, akkor számítógépes információrendszerrôl (informatikai rendszerrôl) beszélünk. Kár Azon érték csökkenése, amelyet valamely objektum jelent egy informatikai rendszer alkalmazásában, és amely akkor következik be, ha valamely fenyegetô tényezô kifejti hatását. Kockázat A fenyegetettség mértéke, amely valamely fenyegetô tényezôbôl ered, és amelyet a kockázatelemzés során a fenyegetô tényezôk értékelése révén tárunk fel. A kockázat két részbôl, a kárnagyságból és a bekövetkezés gyakoriságából tevôdik össze. Konfigurációkezelés A rendszer konfigurációs tételeit azonosító és meghatározó folyamat. Ellenőrzi a tételek kiadását és változásait életciklusuk egészében, feljegyzi és beszámol a konfigurációs tételek és a változtatási kérelmek állapotáról, valamint igazolja a tételek teljességét és hibátlanságát. Maradványkockázat Az a kockázat, amely alapvetôen - kis mértékben - annak ellenére fennmarad, hogy a fenyegetô tényezôk ellen intézkedéseket tettünk. Működôképesség A rendszernek és elemeinek az elvárt és igényelt üzemelési állapotban való fennmaradása. A működôképesség fogalom sok esetben azonos az üzembiztonság fogalommal. Ezen állapot fenntartásának alapfeladatait a rendszer adminisztrátor (rendszer menedzser) látja el. PRINCE A brit kormányzat informatikai részlegeiban használt, szabványos projektirányítási módszer. A szó az angol "Projects In Controlled Environments" (projektek ellenőrzött környezetben) kifejezés rövidítése. Projekt A PRINCE-ben a projektek a következő jellemzőkkel rendelkeznek: • • • •

előírt és egyedileg meghatározott szakmai termékek, az üzleti igények kielégítésére; megfelelő tevékenységek az említett termékek előállításához; biztosított erőforrásmennyiség; véges élettartam;


65/69

• megadott felelősségi körökkel rendelkező szervezeti struktúra. Projekt erőforrásterv Ez a projekt kezdetén előállított felsővezetőknek készülő erőforrásterv. A projekt keretein belül előállított minden termékre kiterjed. Projekt szakmai terv A projekt kezdetén megszülető terv, amely a projek során felmerülő fontosabb tevékenységeket tartalmazza. Ez egy magas szintű, a projekt erőforrástervéhez szorosan kapcsolódó terv. Mindkét tervet felhasználják a projektmunkálatok magas szintű figyelemmel

kísérésére.

A

szakmai

terv

a

minőségellenőrzéssel

és

a

konfigurációkezeléssek kapcsolatos stratégiákkal is foglalkozik. Projektalapítás A projekt alapításakor a projektvezetőségnek biztosítania kell, hogy a projekt világos munkamegbízással és kielégítő irányítási struktúrával rendelkezzen. Projektalapító okirat Ezt a dokumentumot a projektvezetőség a projekt alapításakor jóváhagyja. A következő összetevői vannak: • • • • • • • • • • Program

Megtérülési indoklás Üzleti kockázatok Rendszermeghatározás Üzleti igények Információszükséglet A teljesítés kulcstényezői Szervezet és felelősségi körök Projektterv A kijelölt erőforrások Biztonsági kockázati tényezők

Eljárási leírás, amely valamely informatikai rendszer által közvetlenül vagy átalakítást követôen végrehajtható. Rendelkezésre állás Az a tényleges állapot, amikor is egy informatikai rendszer szolgáltatásai - amely szolgáltatások különbözôk lehetnek - állandóan, illetve egy meghatározott idôben rendelkezésre állnak és a rendszer működôképessége sem átmenetileg, sem pedig tartósan nincs akadályozva. Ebben az összefüggésben jelentôsége van az információ vagy adatok rendelkezésre állásának, elérhetôségének is.


66/69

Rendszer A rendszer a projekt végeredménye, amely minden szakmai terméket tartalmaz (hardver, szoftver, dokumentáció, stb.). A rendszer a projekt életét meghaladóan is létezni fog, sőt továbbfejlesztés esetén már azt megelőzően is létezett. Rendszerprogram (rendszer szoftver) Olyan alapszoftver, amelyre szükség van, hogy valamely informatikai rendszer hardvereit használhassuk és az alkalmazói programokat működtessük. A rendszerprogramok legnagyobb részét az operációs rendszerek alkotják. Sértetlenség, integritás A sértetlenséget általában az információkra, adatokra illetve a programokra értelmezik. Az információk sértetlensége alatt azt a fogalmat értjük, hogy az információkat csak az arra jogosultak

változtathatják

meg

és

azok

véletlenül

sem

módosulnak.

Ez

az

alapveszélyforrás a programokat is érinti, mivel az adatok sértetlenségét csak rendeltetésszerű feldolgozás és átvitel esetén lehet biztosítani. A sértetlenség fogalma alatt gyakran értik a sérthetetlenségen túli teljességet, továbbá az ellentmondás mentességet és a korrektséget, együttesen: integritást. Az integritás ebben az összefüggésben azt jelenti, hogy az információ valamennyi része rendelkezésre áll, elérhetô. Korrektek azok az információk, amelyek a valós dologi vagy - pl. modellezésnél feltételezett állapotot helyesen írják le. SSADM A brit kormányzatban használt rendszerfejlesztési módszer a "Structured Systems Analysis and Design Methodology" rövidítése. Szakmai termékek A projekt szakmai termékeinek nevezzük azokat a termékeket, amelyek kielégítenek egy végfelhasználói funkciót. A szakmai termékeket a projektvezetőség határozza meg a projektalapításkor. Számítógépes bűnözés Azok a bűntettek vagy cselekmények, amelyek informatikai rendszerek, illetve rendszerelemek

ellen

irányulnak

vagy

informatikai

rendszereket

használnak

segédeszközként. Szervezet A kézikönyvben azon szervezeti egység meghatározására szolgáló fogalom, amelyben az informatika

bevezetésének,

alkalmazásának

biztonságát

vizsgálják,

illetve

arról

gondoskodnak.


67/69

Szoftver Valamely informatikai rendszer olyan logikai része, amely a működtetés vezérléséhez szükséges. Támadás Valamely személy (tettes) akciója azzal a szándékkal, hogy valamely informatikai rendszert veszélyeztessen és károkat okozzon. Termék Termék mindaz, amit a projekt előállított. A PRINCE megkülönböztet irányítási termékeket (amelyeket a projekt vezetői hoznak létre), szakmai termékeket (amelyekből a rendszer felépül) és minőségi termékeket (amelyek a minőségbiztosítása kapcsán jönnek létre). Termék lehet a szoftver, hardver vagy dokumentáció, sőt más termékek egy csoportja is. Termékleírás A termékleírás minden termékre vonatkozóan megfogalmazza annak célját, megjelenési formáját és az előírt minőségi kritériumokat. A termékszerkezet minden eleméhez kapcsolódik termékleírás; egy bonyolult termék összetevőit külön termékleírásban fogalmazhatjuk meg, létrehozva egy termékleírás hierarchiát az adott termékre. Védelmi mechanizmusok Olyan védelmi intézkedések, amelyeket biztonsági szabványok határoznak meg a hardver és szoftver gyártó cégek pedig termékeik elôállítása során építik be és szolgáltatják a felhasználók részére.


68/69

7

Felhasznált irodalom

1. ITB ajánlások (4) SSADM strukturált rendszerelemzési és tervezési módszer, www.itb.hu, Budapest, 1993. 2. ITB ajánlások (8) Informatikai biztonság módszertani kézikönyv, www.itb.hu, Budapest, 1994 3. Információmenedzsment (szerk.: Gábor András, Budapest, 2002.) 4. Muha Lajos – Dr. Papp György: Az informatikai biztonság kézikönyve (Verlag Dashöfer Szakkiadó Kft. &T. Bt.), Budapest, 20005. Biró Miklós A kulturális környezet hatása a folyamatok érettségének meghatározására, Budapest, 2007 (előadás a HTE-ben) 6. Rátai Balázs: Biztonság-tudatos fejlesztés, üzemeltetés, IT3 Tanulmányok, Budapest, 2005 december 7. Carnegie Mellon, Software Engineering Institute, +SAFE, V1.2 A Safety Extension to CMMI-DEV, V1.2, Defence Material Organization, Australian Department of Defence, 2007 March 8. Az informatikai biztonság irányításának követelményrendszere (IBIK), Információs Társadalom Koordinációs Tárcaközi Bizottság ajánlása (TERVEZET), 2005. 9. Craigmyle, M., and I. Fletcher, "Improving IT effectiveness through software process assessment", Software Quality Journal, Vol. 2, pp 257-264 (1993). 10. Humphrey, W.S., Managing the Software Process, Addison Wesley, 1989. 11. Kuvaja, P., Simila, J., Krzanik, L., Bicego, A., Koch, G. and Saukkonen, S., Software Process Assessment and Improvement: The BOOTSTRAP Approach. Blackwell, 1994. 12. ISO/IEC 9126 - 1991, Software quality characteristics. 13. ISO/IEC12207-1 - 1994, Software life cycle processes. 14. ISO/IEC12119 -1 995, Software products - Evaluation and test. 15. Biró M.; Remzső,T. Business Motivations for Software Process Improvement. ERCIM News (European Research Consortium for Informatics and Mathematics) No.32 (1998) pp.40-41. 16. Biró M.; Messnarz,R.; Posch,B; Remzső,T.; Stöckler,C; O’Suilleabhain,G.; Velasco,G. A Learning Organisation Approach for Process Improvement in the Service Sector. In: Proceedings of the EuroSPI'2001 Conference (ed. by R.Messnarz). (International Software Collaborative Network, Pori, Finland, 2001) pp.12.13-12.30. 17. The Hungarian Quality Scene - Potential for Co-operation. (with Biró,M.; Feuer,É.) In: Proceedings of the ISCN’2002 Conference on Practical Improvement of Software Processes and Products (ed. by R.Messnarz). (International Software Collaborative Network, Brighton, 2002) pp.56-63.


69/69

MÓDSZERTAN LEÍRÁS. NKTH Biztonsági rendszertervezési módszertan Terjedelem: 69 oldal Készítette: Dr. Remzső Tibor

Recommend Documents