Na kłopoty ze zmianą wymagań
- Radosław Smilgin,
- 07.09.2010
Łatwo jednak zauważyć, że ograniczanie się jedynie do łączenia przypadku testowego z wymaganiem jest marnowaniem dobrze rozpoczętej pracy. Jeśli przypadki są linkowane, to czemu nie zrobić tego samego dla implementacji czy dla błędów? Powstała więc koncepcja Śledzalności Plus oznaczająca, że każdy element wytworzony w ramach projektu jest łączony z elementem, z którego się wywodzi.
Śledzimy projekt
W modelu śledzalności, przed każdą akceptacją lub odrzuceniem zmiany następuje ocena jej wpływu na czas i budżet projektu.
Jeśli jednak dojdzie do akceptacji zmiany, cały projekt informatyczny zmuszony jest do dostosowania się do nowego wymagania. Obieg informacji nie jest jednak w modelu wymuszany z wielu miejsc, a jedynie z jednego. Oszczędza to czas i nakłady na manualne zarządzanie projektem. Zmiana wymagania wymusi np. zmianę implementacji. Może to również oznaczać, że coś, co do tej pory uważane było za defekt, już tym defektem nie jest i zgłoszenie powinno zostać sprawdzone i zamknięte.
Należy także pamiętać, że wymagania stanowią podstawę do tworzenia szeregu dokumentów projektowych. Powinno zatem zostać sprawdzone, czy zmiany mają wpływ na wymagania. Jeśli zmiana wymusza modyfikację dokumentacji, to zmiany w specyfikacji również muszą być odpowiednio zakomunikowane i rozpropagowane w projekcie.
Zalety i wady narzędzia
Wydaje się, że taki model może przynieść jedynie korzyści. Niestety obecnie wdrożenie pełnej śledzalności projektów wymaga zakupu narzędzi od tego samego dostawcy, ponadto są to narzędzia klasy enterprise, z najwyższej półki cenowej. Tylko takie narzędzia gwarantują łatwą integrację i wielokierunkową wymianę informacji. Sam zakup narzędzia nie rozwiązuje problemu, gdyż niezbędne jest prawidłowe jego wdrożenie. Wydatek plus ryzyko nieumiejętnej implementacji narzędzia w organizacji może przełożyć się na straty zamiast korzyści.
Najlepszym rozwiązaniem staje się samodzielna implementacja takiego rozwiązania przy wykorzystaniu narzędzi dostępnych w organizacji. Projekt informatyczny nie musi być tutaj wielki, wystarczy pozbierać dostępne narzędzia do zarządzania wymaganiami, testowaniem, konfiguracją, wersjonowaniem i kodowaniem, i stworzyć platformę komunikacji między nimi. Zbudowanie takiego ekosystemu jest znacznie łatwiejsze, gdy narzędzia są budowane w modelu open source i pochodzą z takich projektów, o wiele trudniej zintegrować kupowane narzędzia od HP, IBM-u czy Microsoftu.