Konfigurációvezérlés-engedje el a bilincset!

az iparágakban és a vertikális ágazatokban az üzleti tevékenység egyre összetettebb, globális jellege, valamint a gyorstüzelő “Internet idő” üzleti modellek új hangsúlyt fektetnek a változáskezelésre. A változás hatékony kezelésének képessége megkülönböztető kulcsként jelenik meg a versenytársak között – lehetővé téve a szervezetek számára, hogy üzleti modelleket és termékvonalakat fejlesszenek ki, és elég gyorsan váltsanak sebességet ahhoz, hogy megfeleljenek a jelenlegi gazdaság lehetőségeinek – a verseny előtt.

ahogy a szervezetek küzdenek a projektek kezeléséért ebben a környezetben, a konfigurációkezelés (CM) egyre kritikusabbá vált, amely keretet kínál a változások kezeléséhez.

a CM tudományága az EIA-649 (ANSI) által meghatározott hat szakterületből áll, 2004))

• CM Planning and Management (Cmpm),
• Configuration Identification (CI),
• Configuration Change Management (CCM),
• Configuration Status Accounting (CSA),
• Configuration Verification & auditok (CVA), és
• CM Digitális adatok.

az ISO 10007 (ISO, 2003) azonban a CM-t négy osztályba sorolja:

• CI,
• Konfigurációvezérlés (CC),
• CSA, és
• konfigurációs felülvizsgálatok és auditok (R& a).

(a CCM és a CC minden gyakorlati szempontból azonos, csakúgy, mint a CVA és az R&A.)

vegye figyelembe, hogy a konfiguráció vezérlését ebben a cikkben tárgyaljuk. A konfigurációs változáskezelés és a változásvezérlés szintén ugyanazon folyamat leírására használt kifejezések.

sok projektmenedzser úgy érzékeli a konfigurációvezérlést, mint visszatartó és korlátozó rendszereket, amelyek célja a termékfejlesztés kaszkadőrje, és ez általában negatív módon befolyásolja a projekt ütemtervét. Sajnos túl gyakran a nagy, összetett programokhoz, például fegyverekhez vagy orvosi rendszerek fejlesztéséhez tervezett általános CC-folyamatokat más típusú projektekre kényszerítik. Ezeket a folyamatokat nem úgy alakították ki, hogy megfeleljenek például egy webfejlesztési erőfeszítésnek vagy egy új termék bevezetésének. Ez végső soron a CC folyamat és a “bilincs” hatás intenzív frusztrációjához vezet – ahol a nem a program igényeinek kielégítésére tervezett folyamatok negatívan befolyásolják a haladást.

a projektmenedzserek konfigurációs vezérlést alkalmaznak a változások vezérlésére és nyomon követésére. A folyamatok célja annak biztosítása, hogy a módosítások jóváhagyásához a megfelelő szintet használják, és hogy ezek a változások a rendelkezésre álló legjobb információkon alapuljanak. A folyamatok keretet biztosítanak a változások felülvizsgálatához. Ez lehetővé teszi a csapat számára, hogy felmérje, elfogadható-e a változtatás végrehajtása, és időben azonosítsa a lehetséges problémákat. Ezek a folyamatok lehetővé teszik a kalibrálást, és szükség esetén további felülvizsgálatot.

az igazi kérdés nem az, hogy végrehajtsuk-e a konfigurációvezérlést, hanem az, hogy milyen szintű konfigurációvezérlést hajtsunk végre. A szervezet minden projekthez megkövetelheti a “vállalati szabvány” konfigurációs vezérlőcsomagot. Az ilyen típusú rendszert gyakran a projektcsapatokra kényszerítik a konfigurációs ellenőrzés hiánya és az ebből eredő pénzügyi hatás miatt. A projektmenedzsereknek, akik felismerik, hogy az “egy mindenki számára megfelelő” megközelítés nem fog működni, bizonyítaniuk kell, hogy megfelelő ellenőrzések vannak érvényben a múltbeli hibák megismétlésének elkerülése érdekében.

Konfigurációvezérlés működés közben

a tipikus fejlesztési projekt nem igényel konfigurációs vezérlési folyamatot egy nagyobb fegyverrendszer szintjén. Fontos, hogy a csapatot megfelelő szintű rugalmassággal ruházzuk fel, miközben biztosítjuk a fékek és ellensúlyok rendszerét. Bármely rendszer kulcsa a folyamat dokumentálásához szükséges erőfeszítés, valamint a folyamat által megkövetelt dokumentáció. Az alábbiakban ismertetett minta CC-eljárást úgy tervezték, hogy megfeleljen egy kis-közepes méretű alkalmazásfejlesztési projekt követelményeinek.

a projektcsapatnak először elemeznie kell a konfigurációvezérlés megfelelő szerepét a projekten. Ez legalább egy szoftverprojekt esetében magában foglalná az összes kódfájl belső dokumentálásának témáját, valamint valamilyen külső dokumentációt. További területek közé tartoznak a változások jóváhagyási és dokumentációs folyamatai. Az érintett résztvevők egyszerű konszenzusának elegendőnek kell lennie. Természetesen a rendszeresen összehívott strukturált testület jobb.

most térjünk át az egyszerű Konfigurációvezérlési folyamat különböző aspektusaira.

dokumentumok

a Konfigurációkezelési terv (CMP) meghatározza a CC folyamatot. Egyes alkalmazásokban, ahol a CC folyamat meglehetősen részletes, Konfigurációvezérlési tervet (CCP) dolgoznak ki. Mindkét esetben minden folyamat és eljárás kiterjed a konfigurációvezérlés végrehajtására.

magának a (később részletezett) módosítási dokumentációnak elegendő olyan információt kell tartalmaznia, amely magától értetődő ahhoz a ponthoz, hogy nem igényel további információkat a kezdeményezőtől. Erre azért van szükség, mert előfordulhat, hogy a kezdeményező nem áll rendelkezésre a változás végrehajtásakor.

folyamat

a CC folyamat egyszerű (1.kiállítás). Az egyénnek van ötlete, vagy hibát talál a jelenlegi rendszerben. Ennek az egyénnek dokumentálnia kell megállapításait egy Enterprise Change Request (ECR) űrlapon, amely az adott projekt összes hibájának, változásának vagy javításának naplózására szolgál. A változtatási kérelmet felülvizsgálatra továbbítják a társaiknak és a felügyelőknek, majd jóváhagyják és végrehajtják.

1.ábra – egyszerű Konfigurációvezérlő folyamat

Változásdokumentáció

a változtatás dokumentálása a konfigurációvezérlő rendszer legkritikusabb része. A dokumentáció részletessége nem olyan fontos, mint a dokumentált információ. A dokumentált információknak azonban le kell írniuk a változást, és legalább a következő információkat kell tartalmazniuk. A dokumentációra vonatkozó minimális követelmények:

természetesen minél több információt tartalmaz a dokumentáció, annál könnyebb újra létrehozni, helyreállítani, elemezni és kijavítani. Ezenkívül ez elősegíti a termék szállításának végleges dokumentációját.

amikor az egyén hibát vagy követelményt fedez fel az aktuális projektben, dokumentálja a szükséges változást. A módosítási kérelem információkat tartalmaz a kérelemről, és leírja a hibát felfedező forgatókönyvet, azt, hogy ki fedezte fel, mikor fedezték fel, valamint az ajánlott javításokat. A kérelemnek meg kell határoznia az érintett konfigurációs elemeket is, ha lehetséges, és valamilyen súlyossági vagy prioritási kódot kell elhelyeznie annak azonosítására, hogy ez a változás mikor történjen, ha jóváhagyják.

módosítás jóváhagyása

a Módosítás jóváhagyásának egy kijelölt projektfelügyelőtől kell származnia, a változás hatásának “nagy kép” nézetével. A szakértői értékelés rendkívül hatékony eszköz a változás valamennyi aspektusának ellenőrzésére és annak biztosítására, hogy a változás által érintett valamennyi területet kezeljék. A fejlesztések szempontjából előnyös lenne, ha az ügyfél egyetértene a változtatással. A kisebb fejlesztési projektekben azonban a legtöbb változás “hibajavítás” típusú, és az ügyfél nem látja a változás hatását.

adatgyűjtés

az adatgyűjtés létfontosságú a hasonló elemek információinak helyreállításához és a trendek és tendenciák felfedezéséhez. Ennek az információnak elektronikusan kell lennie, ami lehetővé teszi az adatok egyszerű helyreállítását és az adatok kezelését az állapotszámvitel és a mutatók tekintetében. Az információk felhasználhatók egy” tanulságok ” jelentés összeállítására, amelyet a szervezeten belül terjesztenek technikai fejlesztés céljából.

Implementáció Módosítása.

miután megkapta az összes megfelelő jóváhagyást, megkezdődik a megvalósítás feladata. A megvalósítás minden lépésének tesztelése ellenőrzi, hogy a program más aspektusaira gyakorolt hatások minimálisak-e. Minden tesztelés befejeződött, és a változás a teljes programban megvalósul.

zárt hurkú folyamat

a siker kulcsfontosságú eleme az a zárt hurkú folyamat, amelyben a változás kezdeményezője tudni fogja a változás végeredményét, mielőtt az megjelenik a végtermékben. Ez minden iparágra igaz, az építőipartól a gyártáson át a szoftverekig.

ez a zárt hurkú folyamat különböző szerepet játszó vezérlőpaneleket állít fel a változtatási folyamatban (2.kiállítás). Minden testületnek kötelessége, hogy alapokmánya teljes összefüggésében felülvizsgálja a változást, és minden egyes változtatásra vonatkozóan végleges döntést hozzon. Természetesen a testület további információkat kérhet, mielőtt meghozhatja ezt a döntést, de ennek minimálisnak kell lennie.

az Institute for Configuration Management (ICMHQ) oktatja a cmii (CMIIU) módszertant a konfigurációkezeléshez, és kifejlesztette ezt a nézetet a zárt hurkú változási folyamatról. Ez a folyamat a végelemmel kezdődik és végződik. Vegye figyelembe, hogy a konfigurációváltozás-adminisztráció a hurkon belül három különböző szinten jelenik meg. Minden terület másként van meghatározva, és sajátos szerepekkel és felelősségekkel rendelkezik.

• műszaki felülvizsgálat-biztosítja, hogy minden részletes értékelés és megvalósíthatósági elemzés teljes legyen.
• a Change Review Board (CRB) – értékeli a változás üzleti hatását. Ez a változás érvényes az üzleti környezetünkre? Megfelel-e stratégiai céljainknak? Beleillik a jövőképünkbe? Jóváhagyott változtatás esetén a CRB a verseny előrejelzésétől és az üzleti kockázatoktól függően megjelölheti vagy nem jelölheti meg a változtatás időkeretét.
• a változás végrehajtó testülete (CIB) – elosztja a szükséges finanszírozást, és meghatározza a változás végrehajtásának határidejét. Ez magában foglalja a változás hatékonyságának hozzárendelését is, amely meghatározza, hogy a változás mikor érvényes. A hatékonyság vonatkozhat egy dátumra, épít, sorozatszám, vagy tételszám. Ez a végponttól függ.

a hurok gyorsított opciója az, ahol a CC minden fájdalma felszabadul, és a tulajdonosok megváltoztathatják a jóváhagyott perceket napokkal szemben. Ennek kulcsa természetesen az egyes termékek megfelelő dokumentációs fája. Minden dokumentumhoz hozzá kell rendelni egy alkotót és egy felhasználót. Ha a változások csak az alacsony szintű dokumentációt érintik, akkor a gyorsított eljárás rendben van, és a változás a CC folyamaton keresztül sikít.

Összegzés

a sikeres Konfigurációvezérlési folyamat kulcsa a teljes projektcsapat nevezési díja. A csapattagokat nem szabad arra kérni, hogy lemondjanak a józan ítélőképességről és az ellenőrzésről egy olyan irányítási infrastruktúra érdekében, amelyet nem úgy terveztek, hogy megfeleljen a szóban forgó projekt követelményeinek. A konfigurációvezérlési folyamatokat úgy tervezték, hogy csökkentsék a meghibásodás kockázatát, és biztosítsák, hogy a teljesítések időben és költségkereten belül teljesüljenek. Ha a projektcsapat részt vesz a kezdeti Konfigurációvezérlési keretrendszer létrehozásában-a projektcsapat részvétele és elfogadása felgyorsul, és a létrehozott infrastruktúra támogatja az üzleti célokat.