Nie ma doskonale prowadzonych i idealnie zarządzanych projektów informatycznych. Są jedynie takie, w których kierownik projektu miał wystarczająco dużo szczęścia i sprzyjające środowisko, żeby projekt ukończyć. Czy rzeczywiście musimy polegać na szczęściu? Oczywiście, że musimy. Możemy jednak pomóc szczęściu, wdrażając śledzalność jako broń w walce ze zmianą.

Największym problemem dla większości projektów informatycznych są wymagania i ich niestabilność w czasie. Osoba zlecająca wytworzenie oprogramowania na początku swojego procesu definiowania założeń nie do końca wie, jaki produkt chce otrzymać. Stąd i same wymagania na oprogramowanie są nieprecyzyjne. W czasie trwania projektu (najczęściej po pierwszym odbiorze) pojawiają się zmiany lub "doprecyzowania", które w rzeczywistości są również zmianami. Prosty projekt, o którym marzy każdy kierownik, to taki, w którym od początku do końca nie ma zmian. Ponieważ jest to utopia, ważny staje się proces zarządzania zmianą i jej kontroli w czasie i przestrzeni projektowej.

Składniki projektu

Na projekt informatyczny składa się wiele pośrednich produktów, których nie pokazujemy klientowi czy użytkownikowi oprogramowania. Z jednej strony wiemy, że dla normalnego człowieka jest to techniczny bełkot, z drugiej strony niewielkie jest zainteresowanie półproduktami z punktu widzenia odbiorcy oprogramowania. Wiedzą o tym doskonale "agileowcy", próbujący zmusić klienta do większego zaangażowania w proces produkcji oprogramowania.

W większości modeli wytwarzania oprogramowania występują podobne produkty i półprodukty. Można znaleźć w niej elementy, które nie zostaną przekazane do klienta jak plany, specyfikacja testowa czy kodowania. Taki element jak pośrednia wersja oprogramowania nie zostanie przekazany klientowi bez spełnienia warunku stabilności i wymagań odbiorcy. Prawdopodobnie błędy, które zostały poprawione również będą przed klientem ukrywane. Nie zmienia to faktu, że były przyczyną zmian, zostały przygotowane i zmieniają się w ogólnym cyklu wytwarzania oprogramowania.

Czym jest śledzalność?

Już wiele lat temu zidentyfikowano kłopot częstych zmian wymagań i konieczności zmian powiązanych z nimi przypadków testowych. Powstał więc model mapujący przypadki testowe do źródłowych wymagań. Takie powiązanie nazywamy śledzalnością. W idealnym modelu każda zmiana wymagań powoduje, że wymuszona jest zmiana przypadku testowego, którego dotyczy. Realizacja wymuszenia jest zazwyczaj automatyczna i autor przypadku testowego, lub też osoba odpowiedzialna za przypadki jest informowana o zmianie, np. za pomocą poczty elektronicznej. Korzyści stojące za takim zarządzaniem zmianą to przede wszystkim przejrzystość w projekcie i łatwiejsze zarządzanie pracą (w tym estymowanie). Są również inne korzyści, jak np. kalkulowanie poziomu pokrycia wymagania przez przypadki testowe czy sprawdzanie, w jakim zakresie udało się dane wymaganie zweryfikować testami. W wielu projektach stanowi to podstawę oceny kompletności oprogramowania.