Trakcie życia oprogramowania zmiany wymagań są nieuniknione. Powodem zmian w wymaganiach mogą być wykryte błędy, nowe lub zmienione cele interesariuszy, zmiany prawne, udostępnienie nowych technologii, czy zmiany na rynku, w którym funkcjonuje organizacja klienta.
Zmiany w wymaganiach same w sobie nie są negatywne i mogą świadczyć o dużym zainteresowaniu interesariuszy tworzonym lub wdrożonym systemem.
Natomiast jeżeli zmiany do wymagań zgłaszane są zbyt często, to rozwój systemu, który będzie spełniał wymagania wszystkich interesariuszy jest praktycznie niemożliwy. Zbyt częste zgłaszanie zmian wskazuje na niewłaściwie przeprowadzone czynności w ramach inżynierii wymagań (akwizycję, dokumentację, walidację i negocjację).
Komisja kontroli zmian
Do prawidłowego zarządzania wymaganiami należy określić w jaki sposób zmiany w wymaganiach mogą być zgłaszane oraz jak powinien przebiegać proces zgłaszania, akceptacji i wprowadzania zmian. Aby zapanować nad procesem zarządzania zmianą należy określić komisję kontroli zmian (ang. change control board, CCB).
Zadania komisji kontroli zmian:
- Oszacowanie nakładu pracy potrzebnego do wprowadzenia zmian.
- Ocena zgłoszenia zmiany, np. w odniesieniu do nakładu / korzyści.
- Zdefiniowanie zmiany wymagania lub nowego wymagania na podstawie zgłoszenia zmiany.
- Akceptacja lub odrzucenie propozycji zmiany.
- Klasyfikacja przychodzących zgłoszeń zmiany.
- Nadawanie priorytetów dla zaakceptowanych zmian.
- Przypisanie zaakceptowanych zgłoszeń zmian do projektów zmian.
Skład komisji kontroli zmian:
- Menadżer zmian
- Dostawca
- Architekt
- Deweloper
- Menadżer konfiguracji
- Pełnomocnik klienta
- Menadżer produktu
- Menadżer projektu
- Pełnomocnik ds. jakości
- Inżynier wymagań
Przewodniczącym komisji jest menadżer zmian.
Zgłoszenie zmiany
Każde zgłoszenie zmiany wymagania powinno być odpowiednio udokumentowane. Aby zarządzanie zmianami mogło być przeprowadzane sprawnie w obrębie projektu powinny być określone szablony dla zgłaszanych zmian.
Zawartość szablonu zgłoszenia zmiany
Minimalny zakres zgłoszenia zmiany to:
- Identyfikator: Unikalny identyfikator pozwalający na identyfikację zgłoszenia.
- Tytuł: Tytuł powinien zawierać podstawowe informacje dotyczące zmiany.
- Opis: Jak najdokładniejszy opis zmiany wymagania wraz ze wskazaniem efektu jaki zostanie osiągnięty przez wprowadzenie zmiany.
- Uzasadnienie: Powody dla których zmiana powinna zostać wprowadzona.
- Data zgłoszenia
- Zgłaszający: Nazwa osoby zgłaszającej zmianę.
- Priorytet (wg zgłaszającego): Określenie rangi zmiany w opinii zgłaszającego.
Informacje dotyczące zarządzania zmianą
W czasie weryfikacji zgłoszenia zmiany warto jest dopisać takie atrybuty jak:
- Osoba sprawdzająca: Osoba, która sprawdza, czy zmiana została wprowadzona poprawnie.
- Status analizy: Flaga informująca czy została przeprowadzona analiza dla tego zgłoszenia zmiany.
- Status decyzji: Flaga określająca czy została podjęta decyzja dotycząca zgłoszenia zmiany przez komisję kontroli zmiany.
- Priorytet: Określa priorytet przypisany zgłoszeniu zmiany przez komisję kontroli zmiany.
- Osoba odpowiedzialna: Określa osobę, która jest odpowiedzialna za wprowadzenie zmiany.
- Wydanie systemu: Określa, w którym wydaniu systemu zmiana zostanie zaimplementowana.
Klasyfikacja przychodzących zgłoszeń zmiany wymagań
Po wpłynięciu zgłoszenia zmiany wymagania menadżer zmian oraz komisja kontroli zmiany musi dokonać klasyfikacji wymagania. Zgłoszenie zmiany może zostać przypisany do jednej z kategorii:
- Zmiany wymagań naprawcze: Zgłoszenie jest klasyfikowane w tej kategorii, jeżeli powodem jego wpłynięcia była awaria funkcjonującego systemu, która wynikła z błędu w wymaganiach.
- Zamiany wymagań adaptacyjne: Zgłoszenie zmiany jest klasyfikowane w tej kategorii, jeżeli wymaga zmiany systemu. Możliwym powodem zgłoszenia zmiany adaptacyjnej mogą być zmiany w otoczeniu systemu.
- Zmiany wyjątkowe (hotfix): Zgłoszenie zmiany jest klasyfikowane jako wyjątkowe, jeżeli wprowadzenie zmian musi być absolutnie wprowadzone natychmiastowo bez względu na koszty. Zmiany wyjątkowe mogą być naprawcze lub adaptacyjne.
Podstawowa metoda dla obsługi zmian naprawczych i adaptacyjnych
Na koniec pytanie: Jakich narzędzi używać? Preferuję albo Enterprise Architect’a albo JIRA. Narzędzie jest wtórne. Liczy się odpowiedni workflow zarządzania zmianą oraz dyscyplina wszystkich interesariuszy do przestrzegania przyjętych zasad.
Tekst zainspirowany książką: Klaus Pohl, Chris Rupp „Requirements engineering fundamentals : a study guide for the Certified Professional for Requirements Engineering exam : foundation level”, IREB compliant Wydawnictwo: Rocky Nook Inc, 2011
