Ovládání konfigurace-uvolněte pouta!

stále složitější, globální charakter podnikání ve všech odvětvích a vertikální odvětví, spolu s rychlým-oheň, “Internet Time” business modely, je hnací silou nové důrazem na řízení změn. Schopnost efektivně řídit změny se objevují jako diferenciační klíč mezi konkurenty – umožňuje organizacím vyvíjet obchodní modely a produktové řady, a změnit rychlost dostatečně rychle, aby vyhovovaly příležitosti současné ekonomiky – náskok před konkurencí.

Jako organizace snaží řídit projekty v tomto prostředí, Configuration Management (CM), má stát stále rozhodující složkou, která nabízí rámec pro řízení změn.

disciplína CM se skládá ze šesti odborných oblastí definovanou EIA-649 (ANSI, 2004))

• CM, Plánování a Řízení (CMPM),
• Konfigurace Identifikace (CI),
• Změna Konfigurace Řízení (CCM),
• Configuration Status Accounting (ČSA),
• Konfigurace Ověřování & Auditů (CVA), a
• CM Digitální Data.

Nicméně, ISO 10007 (ISO, 2003) skupin CM do čtyř klasifikací:

• CI,
• Konfigurace Ovládání (CC),
• ČSA, a
• Konfigurace Přezkumy a Audity (R&).

(CCM a CC jsou pro všechny praktické účely stejné, jako jsou CVA a R&A)

Všimněte si, že konfigurace ovládání je popsána v tomto článku. Správa změn konfigurace a řízení změn jsou také termíny používané k popisu stejného procesu.

Mnoho projektových manažerů vnímat kontrolu nastavení jako omezující a svazující – systémy navrženy tak, aby trik vývoj produktu a to obvykle dopadů projektu je plán v negativním způsobem. Bohužel příliš často generické CC procesy určené pro velké, složité programy, jako jsou zbraně nebo vývoj lékařských systémů, jsou ukládány na jiné typy projektů. Tyto procesy nejsou přizpůsobeny potřebám, například, úsilí o vývoj webu nebo zavedení nového produktu. To nakonec vede k intenzivní frustraci z procesu CC a efektu “pouta” – kde procesy, které nejsou navrženy tak, aby vyhovovaly potřebám programu, negativně ovlivňují pokrok.

projektoví manažeři implementují řízení konfigurace pro řízení a sledování změn. Procesy jsou navrženy tak, aby zajistily, že ke schvalování změn bude použita odpovídající úroveň a že tyto změny budou založeny na nejlépe dostupných informacích. Procesy poskytují rámec pro přezkum změn. To umožňuje týmu posoudit, zda je implementace změny přijatelná, a včas identifikovat potenciální problémy. Tyto procesy umožňují kalibraci a v případě potřeby další revizi.

skutečnou otázkou není, zda implementovat řízení konfigurace, ale jakou úroveň řízení konfigurace implementovat. Organizace může u všech projektů vyžadovat balíček řízení konfigurace “standard společnosti”. Tento typ systému je často uložen projektovým týmům kvůli historii nedostatečné kontroly konfigurace a výslednému finančnímu dopadu. Projektoví manažeři, kteří uznávají, že přístup “one-size-fits-all” nebude fungovat, musí prokázat, že jsou zavedeny vhodné kontroly, aby se zabránilo opakování minulých chyb.

řízení konfigurace v akci

typický vývojový projekt nevyžaduje proces řízení konfigurace na úrovni hlavního zbraňového systému. Je důležité posílit tým s odpovídající úrovní flexibility a zároveň zajistit, aby byl zaveden systém kontrol a vyvážení. Klíčem k jakémukoli systému je úsilí potřebné při dokumentaci procesu spolu s dokumentací požadovanou procesem. Ukázkový proces CC popsaný níže je navržen tak, aby splňoval požadavky malého až středně velkého projektu vývoje aplikací.

projektový tým by měl nejprve analyzovat příslušnou úlohu řízení konfigurace v projektu. To by přinejmenším na softwarovém projektu znamenalo téma vnitřní dokumentace všech kódových souborů a nějaký typ externí dokumentace. Mezi další oblasti, které je třeba pokrýt, patří procesy schvalování změn a dokumentace změn. Stačí jednoduchý konsensus zúčastněných účastníků. Strukturovaná Rada svolávaná pravidelně je samozřejmě lepší.

nyní se podívejme na různé aspekty jednoduchého procesu řízení konfigurace.

dokumenty

plán správy konfigurace (CMP) definuje proces CC. V některých aplikacích, kde je proces CC poměrně podrobný, je vyvinut plán řízení konfigurace (CCP). V obou případech jsou zahrnuty všechny procesy a postupy pro provádění řízení konfigurace.

Změnit dokumentaci samotné (podrobně později) musí poskytnout dostatek informací, že je samozřejmý bod nevyžadující další informace od původce. To je nutné z důvodu možnosti, že původce nemusí být k dispozici v době provedení změny.

proces

proces CC je jednoduchý (exponát 1). Jednotlivec má nápad nebo najde chybu v aktuálním systému. Tato osoba by měla zdokumentovat svá zjištění na Enterprise Change Request (ECR), formulář používaný k zaznamenávání všech chyb, změn nebo vylepšení pro daný projekt. Žádost o změnu je směrována kolegům a nadřízeným k přezkoumání a poté schválena a implementována.

příloha 1 – Jednoduchá Konfigurace Řízení Procesu

Změnit Dokumentace

Dokumentující změnu je nejdůležitější část konfigurace řídicího systému. Detail dokumentace není tak důležitý jako dokumentované informace. Zdokumentované informace však musí popisovat změnu a obsahovat minimálně následující informace. Minimální požadavky na dokumentaci jsou:

samozřejmě, čím víc informací obsažených v dokumentaci, tím snazší je, aby obnovit, obnovit, analyzovat a opravit. Kromě toho to pomůže v konečné dokumentaci pro dodání produktu.

když jednotlivec zjistí chybu nebo požadavek v aktuálním projektu, dokumentuje požadovanou změnu. Žádost o změnu obsahuje informace o požadavku a popisuje scénář, který chybu objevil, kdo ji objevil, když byla objevena, a Doporučené opravy. Žádost by měla také identifikovat položky konfigurace ovlivněna, pokud je to možné, a místo nějaké závažnosti nebo přednostní kód pro identifikaci, kdy tato změna, pokud bude schválen, by mělo dojít.

schválení změny

schválení změny by mělo pocházet od určeného vedoucího projektu s” velkým obrazem ” pohledu na dopad změny. Peer review je vysoce účinným prostředkem k ověření všech aspektů změny a zajištění řešení všech oblastí, kterých se změna týká. Mít zákazníka souhlasit se změnou by bylo prospěšné pro vylepšení. V malých vývojových projektech je však většina změn typu” Oprava chyb ” a zákazník by neviděl dopad změny.

sběr dat

sběr dat je zásadní pro obnovu informací o podobných položkách a objevování trendů a tendencí. Tyto informace by měly být umístěny elektronicky, což umožňuje snadné obnovení dat a manipulaci s daty pro stavové účetnictví a metriky. Tyto informace lze použít k sestavení zprávy “poučení”, která je distribuována v celé organizaci za účelem technického zlepšení.

Změna Implementace.

jakmile obdrží všechna příslušná schválení, začíná úloha implementace. Testování na každém kroku implementace ověřuje, že dopady na další aspekty programu jsou minimální. Veškeré testování je dokončeno a změna je implementována do celého programu.

proces uzavřené smyčky

proces uzavřené smyčky, ve kterém bude původce změny znát konečný výsledek změny dříve, než se objeví v konečném produktu, je klíčovou součástí úspěchu. To platí pro všechny typy průmyslových odvětví, od stavebnictví přes výrobu až po software.

tento proces s uzavřenou smyčkou nastavuje Ovládací panely s různými rolemi v procesu změny (exponát 2). Každá rada má povinnost přezkoumat změnu v plném kontextu své listiny a dospět k definitivnímu rozhodnutí o každé změně. Samozřejmě, rada může vyžadovat další informace, než může učinit toto rozhodnutí, ale to by mělo být minimální.

Institut pro správu konfigurace (ICMHQ) vyučuje metodiku CMII (CMIIU) pro správu konfigurace a vyvinul tento pohled na proces změny v uzavřené smyčce. Tento proces začíná a končí koncovou položkou. Všimněte si, že správa změn konfigurace se ve smyčce zobrazuje na třech různých úrovních. Každá oblast je definována odlišně a má specifické role a odpovědnosti.

• technický přehled-zajišťuje, že všechna Podrobná hodnocení a analýza proveditelnosti jsou kompletní.
• Change Review Board (CRB) – hodnotí obchodní dopad změny. Platí tato změna pro naše podnikatelské prostředí? Splňuje jeden z našich strategických cílů? Zapadá to do našeho prohlášení o vizi? Se schválenou změnou může nebo nemusí CRB uvést časový rámec pro změnu v závislosti na konkurenční prognóze a obchodním riziku.
• Rada pro implementaci změn (CIB) – přiděluje požadované financování a určuje časové rámce implementace změn. To také zahrnuje přiřazení účinnosti změny, která určuje, kdy je změna účinná. Účinnost by se mohla týkat data, sestavení, sériové číslo, nebo číslo šarže. To závisí na koncové položce.

Rychlá volba smyčky je místo, kde je uvolněna veškerá bolest CC a majitelé mohou získat změnu schválenou během několika minut oproti dnům. Klíčem k tomu je samozřejmě správný strom dokumentace pro každý produkt. Každý dokument musí mít přiřazeného tvůrce a uživatele. Pokud změny ovlivní pouze dokumentaci na nízké úrovni, pak je Fast Track v pořádku a změna křičí procesem CC.

shrnutí

klíčem k úspěšnému procesu řízení konfigurace je buy-in od celého projektového týmu. Členové týmu by neměli být požádáni, aby se vzdali řádného úsudku a kontroly v zájmu infrastruktury řízení, která není navržena tak, aby splňovala požadavky daného projektu. Procesy řízení konfigurace jsou navrženy tak, aby snížily riziko selhání a zajistily plnění dodávek včas a podle rozpočtu. Pokud se projektový tým podílí na vytvoření počátečního rámce řízení konfigurace – účast a přijetí napříč projektovým týmem se urychlí a vytvořená infrastruktura podpoří obchodní cíle.