A SzFT tervezése

A SzFT tervezése

Az új SzFT tervezését segítendõ meg kell vizsgálni a szoftverek normális haladását a különbözõ fázisok között a kezdeti fejlesztéstõl/beszerzéstõl az éles felhasználásig. E folyamat minden szakasza használja a konfigurációkezelési adatbázist (KKAB), ill. abban információkat tárol. Az eljárásokat részletesen lásd a következõ pontban!

Eljárások

A kinevezett SzFT-i menedzsernek számos eljárást kell beüzemelnie, hogy segítse a funkció átfogó céljainak elérését. Ezeknek az eljárásoknak kell biztosítania, hogy a szervezet valamennyi szoftver eszköze minõségileg ellenõrizve, biztonságos felügyelet alatt legyen, és csak megfelelõ és engedélyezett kiadások legyenek felhasználhatók az éles környezetben. Ezek az eljárások a funkció követelményeinek/feladatainak valamennyi szempontját/területét fedik, a részleget mûködtetõ személyzettõl azokig az eljárásokig, amelyeket alkalmazva felügyelik a gondjaikra bízott szoftvereket.

Személyzet

Számos tényezõt kell figyelembe venni a SzFT funkció személyzettel való feltöltésénél, a személyzeti szintek és a megkívánt képességek tervezésekor. Néhány a fontosabbak közül:

• A felügyelendõ szoftver KE-ek száma és a funkció által kezelendõ szoftver változtatások/kiadások mérete, gyakorisága és összetettsége.
• A számítógépek/részlegek száma, ahová a kiadásokat teríteni kell.
• A SzFT eljárásait segítõ vagy automatizáló támogató szoftver eszközök elérhetõsége és szolgáltatási szintje.

A SzFT rendkívül fontos része az informatikai struktúrának. Az SzFT az alkalmazásfejlesztés és az éles mûködtetés közötti "kritikus út" része, és közvetlenül részt vesz az élesben használt szoftverek valamennyi változtatásában. Lényeges, hogy a funkció hatékony és eredményes módon mûködjék, és a lehetõ legkisebb mértékben hasson az új vagy megváltoztatott szoftverek bevezetési idejére. Mindezt természetesen ellenõrzött, tervezett és minõségi módon kell elérni, ezért a funkciót ellátó személyzetet gondosan kell kiválasztani, hogy megfelelõ technikai háttérrel és informatikai ismeretekkel, valamint a szervezeti struktúra és az azt támogató alkalmazások alapos ismeretével rendelkezzenek. A kiválasztott személyzet valamennyi tagját teljesen ki kell képezni, és naprakész tudással kell ellátni az összes releváns területrõl. Ide tartoznak:

• a konfigurációkezelés,
• nagygépes szoftver architektúrák,
• alkalmazási struktúrák és használatuk,
• szervezeti követelmények,
• támogató eszközök és segédszoftverek.

Tudatosítás

Számos funkcióra, és azok személyzetére hatással lesz a SzFT funkció bevezetése. Ezen kívül hatni fog olyan más részlegekre is, amelyek kapcsolódnak a "házigazda" részleggel. Ha a funkció nem felügyeli valamennyi szoftvert, akkor eredményessége jelentõs mértékben csökken, ezért lényeges, hogy minden kapcsolódó terület (interfész) értse meg ennek a szolgáltatásnak a helyes használatából eredõ hasznokat.

Ezeket a hasznokat már részleteztük, és ezt ezen a ponton nyomatékosítani kell az új rendszert használó vagy azzal kapcsolatba kerülõ személyzet számára.

politika

tervezése

tervezése

Átfogó kiadási politikát (azaz irányelveket) kell kialakítani, hogy keretet adjon a SzFT-nek. Egy átfogó kiadási politika határozza meg a SzFT és a változtatáskezelés mûködését. Ez a politika, bár lényegében folyamatosan ugyanaz maradhat, rendszeres felülvizsgálatra szorul, hogy alkalmas maradjon az általa támogatott informatikai környezet számára. Az érintett területek közé tartozhatnak az olyan elemek, mint a sürgõs kiadások. Különbözõ szervezeti körülmények között az új vagy módosított szoftverek sürgõs kiadását vezérlõ szabályokat ki kell igazítani. Az szervezeti igények rendszeres szemléje révén, tekintetbe véve a kiadási politikát, ez a fajta változtatás ellenõrizhetõ és tervezhetõ, inkább, mint hogy csupán reagáljanak a változásokra, amelyek túlléphetnek a funkción.

Kiadási egységek megtervezése

Az elsõ cél annak eldöntése, hogy melyik a legmegfelelõbb egység-szint valamennyi szoftver elem vagy elem-típus számára. Ez számos tényezõtõl függ, mint pl. a használatban levõ szoftver-csomagok mérete, a programok típusa, összetettsége, stb. A 22. ábra egy informatikai infrastruktúra négy szintjének egyszerûsített példáját adja. A cél annak eldöntése, hogy ezek közül melyik szinten lesz a kiadási egység. Az egységek itt a RENDSZEREK, amelyek PROGRAMCSOMAGOKBÓL állnak, ezeket PROGRAMOK alkotják, amelyeket viszont MODULOK építenek fel. Ezek közül valamelyik szinten lesz a Kiadási Egység.

Kisebb üzembeállításoknál alkalmas lehet az, hogy a kiadási egység a Rendszer szinten legyen. Emiatt, ha egy a rendszer valamely részét alkotó KE megváltozik, a teljes rendszer szoftver csomagot újra ki kell bocsátani. Ez azonban nagy installációk esetében jelentõs többletterhet jelenthet. Számításba véve az alábbi tényezõket, ugyanezt a gondolatmenetet kell követni annak meghatározásához, hogy vajon a csomag, a program vagy a modul szint illeszkedik-e jobban a szervezet igényeihez. Figyelembe kell venni:

• A szükséges változtatások mennyiségét, összességében, és valamennyi lehetséges egység szinten. Például egy magas szintû változtatás csupán egy program egyetlen meghatározott moduljában a Modul szintet tenné logikussá kiadási egység szintként. Azonban, ha ez a magas szintû változás a modulok nagy részét vagy összességét érinti, akkor a program lehet a leghatékonyabb szint.
• A kiadások kialakításához, teszteléséhez, terítéséhez és üzembe helyezéséhez szükséges idõ- és erõforrás-mennyiség valamennyi szintre. Ez azt jelenti, hogy minél nagyobb az egység, annál nagyobb SzFT erõfeszítés szükséges a változtatás megvalósításához, emiatt nagyobb lehet a hatás az éles szolgáltatásra.
• Az üzembe helyezés egyszerûsége. Például, ha a felhasználók felelõsek az üzembe helyezésért a saját PC-jükön, akkor kívánatos ennek az eljárásnak az egyszerûsítése és a változások elõfordulásának minimumon tartása. Emiatt jobb megoldás lehet a kisebb változtatások visszatartása és periodikus, rendszeres megvalósítása. Ezen kívül, fõleg ha a változások kicsik és modul szintûek, jobb teljes programok kiadása, mint egyedi moduloké.
• A javasolt kiadási egységek és az informatikai infrastruktúra fennmaradó része közti interfészek/kapcsolatok összetettsége. Például, hogy milyen egyszerû az egység leválasztása majd az új egység visszaillesztése a fennmaradó programcsomagokhoz és programokhoz, stb. Természetesen lesz egy határ a változások számában, amely még kielégítõen kezelhetõ egy kiadás esetében; és a kiadás mérete sem haladhatja meg soha azt a mértéket, ami könnyen kialakítható és tesztelhetõ, elfogadható idõtávon belül.

Általánosan véve jobb a változásokat a legalacsonyabb, még praktikus szintre korlátozni; tehát egy teljes program szoftver nem kerül teljes kiadásra, ha csak egy vagy néhány modulja változott. Az is valószínû, hogy ha egy modul több programon belül is jelen van, ennek a változtatása esetén túlzott erõfeszítéseket kívánna a tesztelés, kialakítás és kiadás tevékenységsorának elvégzése valamennyi programnál, csupán ennek az egyetlen modulnak a változtatása miatt.

Különleges esetben, amikor az informatikai infrastruktúrában lehetségesek a csapongó és gyakori változások, megfelelõ megoldást jelenthet, ha a SzFT menedzser a Változtatási menedzserrel együtt a kiadási egységet dinamikusan határozza meg. Ez problémákat jelenthet, de jóval eredményesebb megoldás annál, mint mereven ragaszkodni egy tervhez, ami nem alkalmazható és több problémát okoz, mint amennyit megold.

A másik megfontolandó kérdés a kiadási csomagok alkalmazása. Ezt késõbb tárgyaljuk, de látható lesz, hogy a használatuk bizonyosan kihatással lesz a döntésre a kiadási egység méretérõl.

Nem szabad megfeledkezni arról, hogy a minõségi és az átvételi tesztelés, habár befolyásolja a kiadási egység méretét, lehet, hogy nem értelmezhetõ az adott kiadási egység szinten. Például, ha használatra kibocsátanak egy egyszerû modult, szükséges lehet a hozzá tartozó teljes programrendszerek tesztelése, esetleg még sok más interfész tesztelése is. Általánosságban véve, a tesztelés azokra az elemekre összpontosítson, amelyek megváltoztak, de a fenti szempontokat is figyelembe kell venni.

Delta kiadások

Elõfordulhat, hogy egy teljes egység kiadása nem indokolt. Ilyen esetekben egy delta kiadás alkalmasabb megoldás lehet. Egy delta kiadás csak azokat a KE-eket tartalmazza a kiadáson belül, amelyek aktuálisan megváltoztak vagy újak a legutóbb kiadáshoz képest, amelyek azonban nem alkotnak teljes kiadási egységet. Az elsõ döntés az, hogy vajon megengedjünk-e delta kiadást egyáltalán, és ha igen, milyen körülmények között.

A teljes egység vagy csomag kiadásának legfõbb elõnye az, hogy valamennyi összetevõ együttesen kerül kialakításra, tesztelésre majd terítésre, és az üzembe helyezés is együttesen történik. Ezzel megelõzhetõ az elavult verziók lehetõsége, vagy a teszteletlen interfészek okozta problémák.

Még viszonylag kisebb modul változások esetén is egy teljes egység kiadásának legfõbb hátránya azonban a kialakításhoz, teszteléshez, terítéshez és üzembe helyezéshez szükséges idõ, erõfeszítés és erõforrás (mind emberi, mind számítógépes) mennyisége.

Ezzel szemben elfogadva a delta kiadások átvételének politikáját csökkenthetõk a kialakításhoz szükséges erõfeszítések és a terítéshez és üzembe helyezéshez szükséges munka is.

Egy lehetséges példa egy egyszerû, kicsi javítás megvalósítása miatt kért kiadás. Ilyen körülmények között nehéz lenne indokolni egy teljes kiadási egységhez szükséges erõfeszítéseket. Természetesen lehetséges lenne elhalasztani a javítást egy késõbbi, nagyobb kiadásig. Azonban, ha a javítás fontos és idõkorlátok vannak, politikát kell kidolgozni ezzel kapcsolatban. Azt is látható, hogy a sürgõs változtatások, melyekkel e fejezet késõbbi részében foglalkozunk, gyakran delta típusúak.

Csomag kiadások

Megfontolandó a kiadások csoportosítása csomagokká. Az egyedi kiadások - akár teljes egységek, akár delta kiadások, akár mindkettõ - összevonhatók. Ezt az a helyzet indokolhatja, amikor egy rendszer vagy programcsomag változtatása más rendszerek változtatását is szükségessé teszi - ezeket ugyanis célszerû egy csoportba összevonni.

Olyan környezetben, ahol az élesben használt szoftvert rendszeresen változtatják, alkalmas megoldás lehet az egyedi kiadások csoportosítása egy kiadási csomaggá. Ez hosszabb idõre lehetõvé teszi az éles környezet stabilitását, de másrészrõl megnöveli a SzFT munkaterhelését a csomagok összerakása és a szükséges tesztelés stb. miatt.

A további hasznok:

• Csökken annak a valószínûsége, hogy régi vagy inkompatibilis szoftverek maradjanak használatban.
• Biztosított, hogy valamennyi változás egyidejûleg, rendszeres idõközönként kerül megvalósításra.
• A szoftver minden elemének és interfészének átfogó tesztelése lehetséges.

Kiadások gyakorisága és változás tartalma

Bár a környezet stabilabb lehet, ha a kiadások gyakorisága csökken, azonban nagyobb méretüknél fogva a kiadásokhoz kapcsolódó hibák veszélye nõ. Nyilvánvaló, hogy egyes KE változásai megkívánják más KE-ek ugyanabban az idõben történõ változtatását is. Ennek hatására egyes kiadások nagyobbakká válhatnak, mint ideális esetben lenniük kellene.

Valamennyi szoftver és kiadás típusra meg kell határozni a javasolt kiadási gyakoriságot, eltekintve a sürgõs kiadásoktól. A kiadásoknak mind a gyakoriságát, mind a változási tartalmát (méretét) meg kell határozni, mérlegelve a szoftver által kínált szolgáltatások megszerzése iránti igényt és a túl gyakori és kicsi változások okozta megnövekedett költségeket és stabilitáshiányt. Azonban van határa az együtt megvalósítható változások mértékének.

Sürgõs kiadások

Meg kell határozni a sürgõs kiadásokra vonatkozó eljárásokat.

Kiadás sorszámozás

Minden kiadáshoz egy sorszámot kell rendelni. Két vagy három szintû rendszer megvalósítása ajánlott, melynek felsõ szintjei a jelentõs kiadások számára, az alsóbb szintek pedig a kisebb kiadások számára szolgálnak.

A Hiteles Szoftver Könyvtár tervezése

A HSzK a SzFT funkció magja, lényege. Ez egy biztonságos, logikai terület, ahol valamennyi szoftver KE hiteles, engedélyezett kiadási verzióját tárolják és védik. A tényleges HSzK számos valóságos szoftver könyvtárból áll, amelybe beletartozik egy floppy lemez tároló is a PC-s szoftverek számára. Ideális esetben a HSZK a fejlesztéstõl, a teszt és az éles fájltárolási területektõl elkülönített környezetben található. Elkészítésére tervet kell készíteni, a használatához szükséges eljárásokkal együtt.

A HSzK fogja tartalmazni a forráskódot. Ezt azután a kiadások tárgykódjának létrehozásához használják fel. A vásárolt szoftvereket azonban tárgykód formájukban adják, ezért a HSzK-ban is így kell tárolni õket. Figyelmet kell fordítani annak tisztázására, hogy a HSzK-ban a könyvtár melyik része milyen típusú kódot tartalmaz. A dokumentációt is a HSzK-ban kell tárolni szöveges fájlként, a könnyû kezelés és hordozhatóság érdekében.

Alapvetõen fontos, hogy a HSzK az általa támogatott infrastruktúra valamennyi élesben használt szoftverét tartalmazza, biztonságos módon elhelyezve és felügyelve. Egy katasztrófa vagy szoftver sérülés esetén, ami megakadályozza az éles szoftvernek a mentésekbõl való helyreállítását, a HSzK-ban levõ KE-ek fogják alkotni a helyreállítás alapját. A biztonság érdekében a HSzK elérését kizárólag a SzFT funkció azon személyzetére kell korlátozni, akiknek feladata ellátásához szüksége van rá. A HSzK tartalmát rendszeresen menteni kell, rögzített intervallumonként, vagy lehetõség szerint tartalmának minden felújításakor.

A hardver és operációs rendszer környezet

Ahogy már korábban említettük, a HSzK-nak ideális esetben olyan hardver/szoftver környezetben kell mûködnie, amely elkülönül a rendszertõl, amelyen a kiadás maga kialakításra kerül. Egy több nagygépbõl álló részlegnél ezt viszonylag könnyû megvalósítani. Az ilyen jelegû környezetben még az is lehetséges, hogy eltávolítsuk az éles környezettõl az összes olyan elemet, mint a forráskód, a fordítóprogramok stb., ami növeli a HSzK biztonságát.

Egy kisebb vagy egy géppel rendelkezõ részlegnél ez nyilvánvalóan nem lehetséges. Ebben az esetben tanácsos egy adott célra elkülönített diszk területet fenntartani a HSzK számára, így a kapcsolódás közte és az infrastruktúra fennmaradó része között kettéválasztható, kivéve azt az idõt, amikor a szoftver transzfer folyik.

A HSzK méretezése

A HSzK-at, mielõtt létrehoznánk, méretezni kell. Ebben részt vesz a HSzK menedzser és a Kapacitástervezési menedzser. Tevékenységük során figyelembe kell venniük nemcsak a meglévõ, de a tervezett és jövõbeni igényeket is.

Mikor egy már létezõ szoftvert a funkció átvesz, a méret már értelemszerûen ismert. Új szoftver esetében, a fejlesztés során, a rendszertervezõkkel kell felvenni a kapcsolatot, hogy becslést adjanak a program/modul méretérõl. Jövõbeli szoftverek esetén a becslések a következõkön fognak alapulni:

• a meglévõ javaslatokon,
• a meglévõ szoftverek új verzióin,
• a történeti elemzésekbõl számított jövõbeli trendeken,
• a javasolt szervezeti terveken,
• a lehetséges törvényi/szabályozási változásokon.

Amikor e becslések megtörténtek, el kell dönteni, hogy a KE-ek hány verzióját tároljuk a HSzK-ban. Nyilvánvaló, hogy két verzió megduplázza a méretet, három megtriplázza, stb. Legalább két megelõzõ verzió tárolását érdemes megfontolni a jelenlegi éles verzión kívül. A fájltárolási korlátok ezt megakadályozhatják, ezért a régebbi verziók archiválhatók mágnesszalagra is, azonban ebben az esetben a helyreállítási idõt is figyelembe kell venni.

A HSzK biztonsága

Az éles rendszer karbantarthatósága érdekében biztosítani kell, hogy a HSzK naprakész legyen, és tartalma ne sérülhessen. Bármely romlás esetén az éles vagy a tesztkód mentésekbõl kísérelhetõ meg a visszaállítás, fokozott óvatosság mellett. Ennek megfelelõ eljárásokat kell megtervezni és kialakítani.

Szoftver hozzáadása a HSzK-hoz

Pontosan meg kell határozni és ellenõrizni azon eljárásokat, melyek révén szoftvereket adunk hozzá a HSzK-hoz, hogy megvédjük a HSzK tartalmát, és biztosítsuk, hogy csak engedélyezett KE-ek kerülhessenek bele. Ennek keretében meg kell határozni a személyzetre vonatkozó jogosultságokat, a követendõ eljárásrendet, valamint a minõségi szemlézés módjait.

Szoftver kiadási eljárások tervezése tesztelésre és éles használatra

Eljárásokat kell kidolgozni a kibocsátandó szoftverek üzemeltetési átvételi tesztjére, a tesztkiadás a HSzK-ból való felépítésére, az éles környezetben való összeállításra, a tesztelés valamennyi eredményének naplózására.

Kiadások összeállítására szolgáló eljárások tervezése

A szoftver kiadások felépítési eljárásait meg kell tervezni, ki kell alakítani és dokumentálni, a korábban bemutatottaknak megfelelõen.

Szoftver terítési és üzembe helyezési eljárások tervezése

Eljárásokat kell tervezni és kialakítani a szoftver kiadásoknak az összeállítási környezetbõl a tesztelési és az éles környezet(ek)be való terítésére, és ezekben a környezetekben való használatba állítására.

Szoftverek átdolgozására szolgáló eljárások tervezése

Eljárások szükségesek a szoftverek átdolgozására. Az átdolgozás csak a HSzK-ban tárolt hiteles kódon történhet, ezért eljárások szükségesek annak megakadályozására, hogy a HSzK-on kívüli forrást használjanak fel, ezen kívül eljárások szükségesek a minõség-ellenõrzésre is.

Eljárások meghatározása vásárolt szoftverek esetére

A vásárolt szoftverekhez további eljárások bevezetése megfontolandó, a már tárgyalt kétféle környezetre vonatkozóan:

• Eljárások szükségesek a nagy és minigépekhez - a házon belül fejlesztett szoftverekhez hasonló eljárások szükségesek, figyelembe véve, hogy ez esetben tárgykód formáról van szó.
• Eljárások szükségesek a PC-khez az eredeti diszk megfelelõ tárolására, a HSzK-nak való átadására, az ellenõrzésekre, a másolatok kezelésére, az üzembe helyezésre.

Belsõ készítésû PC szoftverek

Megfelelõ eljárásokkal kell biztosítani, hogy a belsõ készítésû szoftvereket is ugyanolyan módon kezeljék és felügyeljék, mint más szoftvereket. A kevésbé fontos, egy felhasználó céljaira szolgáló szoftverek jelenthetnek csak kivételt, ezeknél bizonyos eljárások elhagyhatók.

A támogató eszközök követelményeinek meghatározása

A szervezeten belül a SzFT menedzsernek kell megállapítani, hogy a meglévõ szoftverek és a jelenlegi eljárásrendek milyen mértékben elégítik ki funkciójának követelményeit, figyelembe véve a szoftverek felügyeletét és terítését.

Ha szükséges, meg kell vizsgálni, hogy mi az, ami külsõ forrásból elérhetõ, hogy olyan lehetõségekhez/szolgáltatásokhoz juthassunk, amit a meglévõ rendszerek nem nyújtanak. Az ilyen csomagokat gyakran a konfigurációkezelés területére sorolják, tehát ezt is meg kell vizsgálni.

Ezután teljes képet lehet kialakítani a SzFT funkciót segítõ beszerezhetõ eszközökrõl. Az elérhetõ eszközök által nem fedett területeket ekkor meg lehet vizsgálni az esetleges házon belüli támogató szoftver fejlesztése szempontjából.

A meglévõ eljárások helyesbítése/módosítása

Ha az új SzFT funkció eljárásai meghatározásra kerültek, akkor tisztázni kell a funkción belüli és a más funkciókhoz való kapcsolódásokat (interfészeket), és ahol szükséges, módosítani kell azokat. Ehhez szükség lehet arra, hogy más funkciók megváltoztassák saját eljárásaikat, ezért a SzFT menedzser munkájával együtt jár, hogy "eladja" a koncepciót és annak elõnyeit a többi menedzsernek, megmutatva a hasznokat mind a funkciók, mind az infrastruktúra egésze szempontjából. Ezek az érintett funkciók, pl.:

• Alkalmazásfejlesztés,
• Számítógép üzemeltetés,
• Hálózatok,
• Változás-felügyelet,
• Konfigurációkezelés,
• üzemeltetési átvételi tesztelés.

A SzFT eljárásainak dokumentációja

Dokumentálni kell mindazokat az eljárásokat, amelyeket a megelõzõ pontokban tárgyaltunk, valamint azokat, amelyek ezután következnek, beleértve az összeállítást, terítést, a szoftvercsomagok üzembe helyezését. E dokumentációnak tartalmaznia kell a funkció kiadási politikáját és a HSzK felügyeleti és karbantartási eljárásait is. Ezen eljárásokat a szervezetnek szemléznie kell, azt biztosítandó, hogy ne befolyásoljanak semmilyen más területet, majd ezután engedélyeztetni kell életbe léptetésüket az informatikai szolgáltatás menedzserrel.

E dokumentáció módosítását ellenõrizni kell, a normál változás-felügyeleti eljárások szerint, a megfelelõ engedélyeztetésnek alávetve.

Megvalósítás

A megvalósítási terv kialakítása

Tervet kell készíteni az új SzFT funkció megvalósításáról. Nem célravezetõ a szervezet által a kezdetektõl tárolt/vezetett teljes KE leltár átvételével próbálkozni. Elõnyösebb, ha korlátozzuk a kezdeti részvételi kört, azaz ha csak az új projektek eredményeire koncentrálunk:

• A HSzK-ban az anyag kezdetben lassan szaporodik, lehetõvé téve, hogy megismerkedjenek az új technikákkal és eszközökkel, amelyeknek használatába egy jobban felügyelt mûködési mód érdekében kezdtek.
• Ez tisztán elhatárolt kezdési pontot biztosít az új funkció és eljárásai használatára, amit az infrastruktúra személyzete könnyebben elfogadhatónak és alkalmazhatónak talál az õsrobbanás ("big bang") megközelítéshez képest.
• Ez a kezdeti tevékenység az új funkcióban az új szoftverek verzióinak elsõ tesztjével együtt folyhat.

Mivel a felhasználók ekkor még nem érintettek közvetlenül, a SzFT eljárásainak esetleges hibája az éles üzemeltetésre nincs tényleges hatással, ami jó tapasztalatszerzési lehetõséget jelent. Mindezt szem elõtt tartva logikus a funkció indítását egy új projekt határidejével együtt idõzíteni.

Eljárások

Amikor a személyzet, a hardver és a támogató eszközök már rendelkezésre állnak, és a személyzet képzése is befejezõdött, a SzFT megvalósításának elsõ fázisa következhet.

Elõször a HSzK és az összeállítási környezet tervezését és létrehozását kell elvégezni. Minden szükséges biztonsági engedélyt ki kell adni, hogy a hozzáférést kizárólag a SzFT személyzetre lehessen korlátozni. Ha ez megtörtént, tesztelni kell a tervezési fázis során már meghatározott kritériumoknak megfelelõen, biztosítva, hogy minden rendben legyen. Ezután mindenkit, akit a változás érint, értesíteni kell, és tudatva velük, mikortól kezdve kell átadni az új szoftver KE-ket a SzFT funkciónak a HSzK-ban való elhelyezésre. Meg kell állapodni az új vásárolt szoftverek elhelyezésérõl is, ezeket közvetlenül a SzFT funkciónak kell átadni.

Ha a már tárgyalt fokozatos megvalósítási megközelítést elfogadták, fontolóra kell venni, hogy a meglévõ szoftverek mikor és hogyan kerüljenek a SzFT ellenõrzése alá. Nyilvánvaló, hogy ez függ a kezdeti megvalósítási szakaszok sikerétõl, de a terv ne legyen túl ambiciózus, mivel a problémák ebben a fázisban elronthatják a funkcióról addig kialakított kedvezõ képet. A kiadás-felügyelet megvalósítására valamikor a HSzK létrehozása után kerül sor. Ezen kívül a kiadás felügyeletének eljárásait is tesztelni kell, mielõtt használatukba kezdenének. A fokozatos megközelítéssel ezek az eljárások kipróbálhatók az elsõ új projekttel, amely a teszt környezetben összeállításra kerül. Továbbá, mire a kiadás eléri az éles környezetet, az eljárások teszteltek és sikeresek lesznek, mivel a velük kapcsolatos problémák és hibák azonosíthatók, ahogy a kiadás a tesztkörnyezetbe kerül.

Az eredeti állapot helyreállítását biztosító terveket kell készíteni arra az esetre, ha az eljárások lényeges részében hiba történne, ami nem javítható ki a rendelkezésre álló idõn belül. Ez jó lehetõség az üzembe helyezési és a terítési eljárások elkülönített tesztelésére, mivel ha az egyik sikertelen (hibázik), a másik még mindig használható. Azonban az elsõ kiadást óvatosan kell megtervezni. (Nem túl jó ötlet úgy dönteni, hogy az elsõ kiadás terítési dátum egyezzék egy a szervezeti infrastruktúra további mûködéséhez fontos kiadás idejével.)

Függõségek

Számos feltételnek kell teljesülnie a SzFT megvalósítása elõtt:

• A SzFT nem mûködhet sikeresen addig, amíg a szolgáltatás-menedzsment más területei nem mûködnek megfelelõen, ideértve a konfigurációkezelést, a változáskezelést és az üzemeltetési átvételi tesztelést. Ha ezek a funkciók még nem léteznek, létre kell hozni, és sikeresen üzemeltetni kell õket, mielõtt a SzFT maga mûködésbe lépne.
• A személyzetet ki kell képezni az új SzFT-i eljárásokra, valamint a hardver és szoftver eszközök használatára, illetve meg kell ismertetni velük a változtatás- és a konfigurációkezelés alapelveit
• A HSzK-at és az összeállítási környezetet ki kell alakítani, majd átfogó tesztelésnek kell alávetni. A támogató eszközöket is be kell szerezni és tesztelni.
• A SzFT funkció valamennyi eljárását és eszközét tesztelni kell, amennyire csak lehetséges, olyan szimulált környezetben, ami az aktuális használatot a lehetõ legjobban tükrözi.

Problémák

A szoftver felügyelet és terítés funkció kialakításának kezdeményezésekor, illetve a mûködtetés során a következõ nehézségekkel szembesülhetünk:

• Lehetséges, hogy a régi eljárásokban jártas személyzet nem látja szívesen a változásokat. Ennek ellensúlyozására a figyelemfelkeltõ kampány során hangsúlyozni kell az új eljárások hasznosságát.
• Megkísérelhetik a SzFT eljárásainak megkerülését. Ezt szigorúan kell kezelni, fõleg ha engedélyezetlen szoftverek kerülnek a szervezetbe, mivel ezek a vírusok és a rossz szándékú beavatkozások fõ forrásai.
• Sürgõs javítások esetén is törekedhetnek a SzFT, a változtatás és a konfigurációkezelés eljárásainak megkerülésére, ami nagy veszélyeket rejt magában.
• Ellenállhatnak annak is, hogy a HSzK-ból kiindulva hajtsanak végre teljes szoftver összeállítást az éles környezetben, ehelyett csupán átmásolják a szoftvert a teszt környezetbõl.
• Osztott rendszereknél komoly gondot okozhat, ha egy szoftver új verziója nem kerül használatba a megfelelõ idõben. Ez megelõzhetõ központi, lehetõleg automatikus felügyeleti eszközökkel és rendszeres konfigurációs audittal.
• A túlzott lelkesedés is gondot okozhat, az új eljárások üzembe helyezésével ugyanis erõs lesz a kísértés, hogy ezen eljárásokat kiterjesszék valamennyi szervezeti szoftverre. Ez azonban fáradságos és pazarló is lenne, kezdetben elegendõ az új eljárásokat csupán az új kiadásokra alkalmazni. Késõbb, ha a felügyelet alá nem vont szoftverek aránya már kicsi, akkor megfontolandó az eljárások kiterjesztése a meglévõ szoftverekre is.
• Sokan túl kényelmetlennek és költségesnek tekintik a SzFT eljárásait, akár az informatikai vezetés tagjai is. Éppen ezért szükséges tudatosítani, hogy a szoftver változások hatékony és eredményes kezelése nélkülözhetetlen tevékenység.