Zmiany w oprogramowaniu i Specyfikacji Wymagań

Jak postępować ze zmianami wymagań ?

Zmiany w oprogramowaniu się zdarzają, często też są niezbędne. Samo zdefiniowanie wszystkich wymagań dotyczących produktu jest często niemożliwe, zmianom ulegają potrzeby biznesowe czy też przepisy. Zarządzanie projektami programistycznymi powinno zagwarantować że:

  • proponowane zmiany w wymaganiach zostaną starannie ocenione przed podjęciem decyzji o ich realizacji,
  • podjęte decyzje o ich realizacji zostaną podjęte przez odpowiednie osoby,
  • wprowadzone zmiany będą widoczne dla wszystkich zainteresowanych,
  • zmiany w wymaganiach dotyczących projektu będą wprowadzane w sposób spójny
  • Jako idealną sytuację uznaje się kaskadowy model rozwoju oprogramowania, który niestety nie sprawdza się w praktyce. Uzasadnione jest „zamrożenie ” wymagań na okres danej iteracji procesu w celu ich realizacji. Natomiast samo ewaluowanie wymagań jest uzasadnione, podyktowane zmianami jak i oczekiwaniami użytkowników. W przypadku, gdy wymagania ulegają zmianom, wprowadzane są nowe funkcje, a zasoby i harmonogram prac pozostaje niezmieniony – dochodzi do zjawiska pełzania zakresu. Zatwierdzanie każdej zmiany, wymaga wprowadzenia zmian w już wykonanym projekcie, co z kolei zagraża terminowemu zakończeniu projektu. Kontrolę nad pełzaniem zakresu można uzyskać poprzez udokumentowanie celów biznesowych, zakresu i ograniczeń systemu. Po zdefiniowaniu wymagań w stopniu wystarczającym do podjęcia pracy nad projektem, zarządzanie zmianami może ograniczyć niekorzystny wpływ  wprowadzanych zmian na projekt . Karl Wiegers i Joy Beatty w „Specyfikacji oprogramowania inżynieria wymagań”  wydanie III , proponują następujący przebieg procesu kontrolowania zmian:
  • kryteria początkowe, tj. warunki, które powinny zostać spełnione przed przystąpieniem do realizacji procesu,
  • rozmaite zadania wykonywane w ramach procesu,
  • czynności weryfikujące poprawność wykonania poszczególnych zadań,
  • kryteria końcowe, czyli okoliczności wskazujące, kiedy proces został pomyślnie zakończony.

Przykładowy szablon opisu procesu kontrolowania zmiany:

  1. Cel i zakres
  2. Role i odpowiedzialność
  3. Stany wnioskowanych zmian
  4. Kryteria początkowe
  5. Zadania
    1. Ocena propozycji zmiany
    2. Podjęcie decyzji
    3. Implementacja zmiany
    4. Weryfikacja zmiany
  6. Kryteria końcowe
  7. Raportowanie statusu zmiany

W celu gromadzenia i zarządzania zmianami zalecane jest korzystanie z narzędzi do kontrolowania zmian.