Kontrola konfiguracji-uwolnij kajdanki!

coraz bardziej złożony, globalny charakter wszystkich przedsiębiorstw w różnych branżach i sektorach pionowych, w połączeniu z szybkimi modelami biznesowymi “czasu internetowego”, kładzie nowy nacisk na zarządzanie zmianami. Zdolność do skutecznego zarządzania zmianami staje się kluczowym elementem wyróżniającym konkurencję – umożliwiając organizacjom ewoluowanie modeli biznesowych i linii produktów oraz zmianę biegów na tyle szybko, aby sprostać możliwościom obecnej gospodarki – wyprzedzając konkurencję.

w miarę jak organizacje mają trudności z zarządzaniem projektami w tym środowisku, Zarządzanie konfiguracją (CM) staje się coraz bardziej krytycznym komponentem, oferującym ramy zarządzania zmianami.

dyscyplina CM składa się z sześciu obszarów wiedzy zdefiniowanych przez EIA – 649 (ANSI, 2004))

• planowanie i zarządzanie CM (CMPM),
• Identyfikacja konfiguracji (CI),
• zarządzanie zmianą konfiguracji (CCM),
• rozliczanie stanu konfiguracji (Csa),
• weryfikacja konfiguracji & audyty (CVA) i
• CM danych cyfrowych.

jednak ISO 10007 (ISO, 2003) grupuje CM w cztery klasyfikacje:

• CI,
• Kontrola konfiguracji (CC),
• CSA i
• przeglądy i audyty konfiguracji (R& A).

(CCM i CC są dla wszystkich praktycznych celów identyczne, podobnie jak CVA i R&A.)

zauważ, że kontrola konfiguracji jest omówiona w tym artykule. Zarządzanie zmianą konfiguracji i kontrola zmian są również terminami używanymi do opisania tego samego procesu.

wielu kierowników projektów postrzega kontrolę konfiguracji jako ograniczanie i ograniczanie – systemy zaprojektowane w celu zahamowania rozwoju produktu, co zwykle wpływa negatywnie na harmonogram projektu. Niestety zbyt często generyczne procesy CC przeznaczone dla dużych, złożonych programów, takich jak rozwój broni lub systemów medycznych, są narzucane innym rodzajom projektów. Procesy te nie są dostosowane do potrzeb, na przykład, wysiłku tworzenia stron internetowych lub wprowadzania nowego produktu. To ostatecznie prowadzi do intensywnej frustracji z procesem CC i efektem “zakuwania” – gdzie procesy Nie zaprojektowane do potrzeb programu negatywnie wpływają na postęp.

kierownicy projektów wdrażają kontrolę konfiguracji, aby kontrolować i śledzić zmiany. Procesy są zaprojektowane w taki sposób, aby zapewnić wykorzystanie odpowiedniego poziomu do zatwierdzania zmian i aby zmiany te były oparte na najlepszych dostępnych informacjach. Procesy te stanowią ramy dla przeglądu zmian. Pozwala to zespołowi ocenić, czy wdrożenie zmiany jest dopuszczalne i zidentyfikować potencjalne problemy w odpowiednim czasie. Procesy te umożliwiają kalibrację, a w razie potrzeby dalszą korektę.

prawdziwym pytaniem nie jest, czy zaimplementować kontrolę konfiguracji, ale jaki poziom kontroli konfiguracji zaimplementować. Organizacja może wymagać pakietu kontroli konfiguracji “standard firmy” we wszystkich projektach. Ten typ systemu jest często narzucany zespołom projektowym ze względu na historię braku kontroli konfiguracji i wynikającego z tego wpływu finansowego. Kierownicy projektów, którzy uznają, że podejście” uniwersalne ” nie zadziała, muszą wykazać, że istnieją odpowiednie kontrole, aby uniknąć powtarzania błędów z przeszłości.

Kontrola konfiguracji w działaniu

typowy projekt rozwojowy nie wymaga procesu kontroli konfiguracji na poziomie głównego systemu uzbrojenia. Ważne jest, aby zapewnić zespołowi odpowiedni poziom elastyczności, zapewniając jednocześnie system kontroli i równowagi. Kluczem do każdego systemu jest wysiłek wymagany w dokumentowaniu procesu, wraz z dokumentacją wymaganą przez proces. Przykładowy proces CC opisany poniżej został zaprojektowany tak, aby spełnić wymagania małego i średniego projektu rozwoju aplikacji.

zespół projektowy powinien najpierw przeanalizować odpowiednią rolę kontroli konfiguracji w projekcie. To, co najmniej w przypadku projektu oprogramowania, wiązałoby się z tematem dokumentowania wszystkich plików kodu wewnętrznie i pewnego rodzaju zewnętrznej dokumentacji. Dodatkowe obszary do omówienia obejmują zatwierdzanie zmian i procesy dokumentacji zmian. Wystarczy prosty konsensus uczestników. Oczywiście, zorganizowany Zarząd zwoływany regularnie jest lepszy.

przejdźmy teraz do różnych aspektów prostego procesu kontroli konfiguracji.

dokumenty

plan zarządzania konfiguracją (CMP) określi proces CC. W niektórych aplikacjach, w których proces CC jest dość szczegółowy, opracowywany jest plan kontroli konfiguracji (CCP). W obu przypadkach wszystkie procesy i procedury są objęte kontrolą konfiguracji.

sama dokumentacja zmian (szczegółowa później) musi dostarczyć wystarczająco dużo informacji, które są oczywiste do tego stopnia, że nie wymagają dodatkowych informacji od twórcy. Jest to wymagane ze względu na możliwość, że twórca może nie być dostępny do czasu wdrożenia zmiany.

proces

proces CC jest prosty (przykład 1). Osoba ma pomysł lub znajduje błąd w obecnym systemie. Osoba ta powinna udokumentować swoje ustalenia na Enterprise Change Request (ECR), formularz używany do rejestrowania wszystkich błędów, zmian lub ulepszeń dla danego projektu. Żądanie zmiany jest kierowane do partnerów i przełożonych do przeglądu, a następnie zatwierdzane i wdrażane.

dowód 1 – prosty proces sterowania konfiguracją

dokumentacja zmian

dokumentowanie zmian jest najbardziej krytyczną częścią systemu sterowania konfiguracją. Szczegóły dokumentacji nie są tak ważne jak informacje, które są dokumentowane. Jednak udokumentowane informacje muszą opisywać zmianę i zawierać co najmniej następujące informacje. Minimalne wymagania dotyczące dokumentacji to:

oczywiście im więcej informacji zawartych jest w dokumentacji, tym łatwiej jest ją odtworzyć, odzyskać, przeanalizować i poprawić. Ponadto pomoże to w ostatecznej dokumentacji dostawy Produktu.

gdy dana osoba odkryje błąd lub wymóg w bieżącym projekcie, dokumentuje wymaganą zmianę. Żądanie zmiany zawiera informacje o żądaniu i opisuje scenariusz, w którym wykryto błąd, kto go odkrył, kiedy został wykryty, oraz zalecane poprawki. Żądanie powinno również, jeśli to możliwe, zidentyfikować elementy konfiguracji, których to dotyczy, i umieścić pewien rodzaj kodu ważności lub priorytetu, aby określić, kiedy ta zmiana, jeśli zostanie zatwierdzona, powinna nastąpić.

zatwierdzenie zmiany

zatwierdzenie zmiany powinno pochodzić od wyznaczonego kierownika projektu z “dużym obrazem” wpływu zmiany. Wzajemna ocena jest wysoce skutecznym środkiem weryfikacji wszystkich aspektów zmiany i zapewnienia, że wszystkie obszary, których dotyczy zmiana, zostaną uwzględnione. Zgoda klienta na zmianę byłaby korzystna dla ulepszeń. Jednak w małych projektach deweloperskich większość zmian jest typu “bug fix” i klient nie zobaczy wpływu tej zmiany.

gromadzenie danych

gromadzenie danych jest niezbędne w odzyskiwaniu informacji o podobnych elementach i odkrywaniu trendów i tendencji. Informacje te powinny znajdować się w formie elektronicznej, co pozwala na łatwe odzyskiwanie danych i manipulowanie danymi w celu księgowania stanu i wskaźników. Informacje te mogą być wykorzystane do sporządzenia raportu “wyciągnięte wnioski”, który jest dystrybuowany w całej organizacji w celu poprawy technicznej.

Implementacja Zmian.

po otrzymaniu wszystkich odpowiednich zatwierdzeń rozpoczyna się zadanie wdrożenia. Testy na każdym etapie wdrażania weryfikują, czy wpływ na inne aspekty programu jest minimalny. Wszystkie testy są zakończone, a zmiana jest zaimplementowana w całym programie.

proces w zamkniętej pętli

proces w zamkniętej pętli, w którym twórca zmiany będzie wiedział o ostatecznym wyniku zmiany, zanim pojawi się ona w produkcie końcowym, jest kluczowym elementem sukcesu. Dotyczy to WSZYSTKICH rodzajów branż, od budownictwa po produkcję i oprogramowanie.

ten proces w pętli zamkniętej ustawia tablice kontrolne z różnymi rolami w procesie zmiany (Dowód 2). Każda rada ma obowiązek przeglądu zmian w pełnym kontekście swojego statutu i podjęcia ostatecznej decyzji w sprawie każdej zmiany. Oczywiście Rada może wymagać dodatkowych informacji, zanim będzie mogła podjąć tę decyzję, ale powinno to być minimalne.

Instytut zarządzania konfiguracją (Icmhq) uczy metodologii zarządzania konfiguracją CMII (CMIIU) i opracował ten widok procesu zmiany w pętli zamkniętej. Ten proces rozpoczyna się i kończy z elementem końcowym. Zauważ, że administracja zmianą konfiguracji pojawia się na trzech różnych poziomach w pętli. Każdy obszar jest inaczej zdefiniowany i ma określone role i obowiązki.

• przegląd techniczny-zapewnia, że wszystkie szczegółowe oceny i analizy wykonalności są kompletne.
• Change Review Board (CRB) – ocenia wpływ zmiany na biznes. Czy ta zmiana jest ważna dla naszego środowiska biznesowego? Czy spełnia jeden z naszych celów strategicznych? Czy pasuje to do naszej wizji? W przypadku zatwierdzonej zmiany CRB może, ale nie musi, wskazywać ramy czasowe zmiany w zależności od prognozowania konkurencji i ryzyka biznesowego.
• Rada ds. wdrażania zmian (ang. Change Implementation Board, CIB) – przydziela wymagane fundusze i określa ramy czasowe wdrażania zmian. Obejmuje to również przypisanie efektywności dla zmiany, która określa, kiedy zmiana jest skuteczna. Skuteczność może odnosić się do daty, budowy, numeru seryjnego lub numeru partii. Jest to zależne od elementu końcowego.

opcja Szybkiej ścieżki pętli to miejsce, w którym uwalniany jest cały ból CC, a właściciele mogą uzyskać zatwierdzenie zmiany w ciągu kilku minut w porównaniu z dniami. Kluczem do tego jest oczywiście odpowiednie drzewo dokumentacji dla każdego produktu. Każdy dokument musi mieć przypisanego twórcę i użytkownika. Jeśli zmiany mają wpływ tylko na dokumentację niskiego poziomu, szybka ścieżka jest w porządku, a zmiana krzyczy przez proces CC.

podsumowanie

kluczem do pomyślnego procesu kontroli konfiguracji jest wpisowe od całego zespołu projektowego. Członkowie zespołu nie powinni być proszeni o rezygnację z należytego osądu i kontroli na rzecz infrastruktury zarządzania, która nie jest zaprojektowana tak, aby spełniała wymagania danego projektu. Procesy kontroli konfiguracji zostały zaprojektowane w celu zmniejszenia ryzyka awarii i zapewnienia realizacji rezultatów na czas i zgodnie z budżetem. Jeśli zespół projektowy uczestniczy w tworzeniu wstępnego systemu kontroli konfiguracji-udział i akceptacja w całym zespole projektowym jest przyspieszona, a utworzona infrastruktura będzie wspierać cele biznesowe.