Na kłopoty ze zmianą wymagań
- Radosław Smilgin,
- 07.09.2010
Powstał model mapujący przypadki testowe do źródłowych wymagań. Takie powiązanie nazywamy śledzalnością.
Model śledzalności nawet w swojej szczątkowej wersji nie jest popularny w środowisku polskich projektów informatycznych. Proces śledzalności wydaje się kosztowny w implementacji, ale korzyści z niego płynące to nie tylko optymalne zarządzanie zmianą. Nie wolno nam zapomnieć, że organizacja musi zbierać, przetwarzać i archiwizować informacje. Jest to podstawowa cecha firm, które chcą eliminować błędy przeszłych projektów. Śledzalność jest optymalnym rozwiązaniem do osiągnięcia statusu organizacji uczącej się.
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.