Duży projekt, zmienne wymagania

Artykuł został opublikowany w Teleinfo

W przypadku dużych projektów, zwłaszcza prowadzonych na zlecenie instytucji publicznych, firmy IT często muszą zmagać się istotnymi zmianami wymagań w trakcie budowy aplikacji. Dlatego kluczową sprawą dla wykonawcy jest zbudowanie dobrego procesu zarządzania wymaganiami. Najlepiej jeśli zostanie on wpisany do umowy w postaci dobrze zdefiniowanych terminów, zasad i procedur, niezbędnych do bezkonfliktowego wprowadzania zmian dotyczących zakresu, czasu realizacji i budżetu projektu. Odbiorcy twierdzą, że dokładnie wiedzą, czego chcą i protestują przeciwko takim zapisom, jednak firmy, które specjalizują się w tworzeniu i implementacji dużych systemów IT, stale doświadczają licznych i istotnych zmian wymagań, co musi skutkować częstym renegocjowaniem umowy. Muszą więc zadbać o uświadomienie zlecającemu konsekwencji jakie wiążą się z wprowadzaniem zmian do systemu w kolejnych fazach jego realizacji.

- ABG Ster-Projekt był odpowiedzialny za tworzenie oprogramowania dla systemu IACS. W trakcie realizacji tego projektu prowadziliśmy listę 700 istotnych wymagań, z których ponad 400 uległo zmianie. Zasady działania systemu zmieniły się niemal w całości. Te doświadczenia dowodzą, jak ważne jest edukowanie zlecającego w obszarze zarządzania wymaganiami i specyfiki procesu twórczego - powiedział Bogusław Machowski, dyrektor Centrum Projektowania i Realizacji Systemów, ABG Ster-Projekt.

PROCES WYTWÓRCZY

Brak zrozumienia specyfiki procesu tworzenia oprogramowania powoduje, że zamawiający nie jest świadomy konsekwencji, jakie wiążą się z wprowadzeniem zmian w trakcie jego realizacji. Najlepiej jeszcze na etapie przetargu zorganizować prezentację procesu wytwórczego, na której obecny będzie nie tylko zarząd, ale również osoby odpowiedzialne później za współpracę z dostawcą. Niezbędne są też odpowiednie szkolenia dla osób, mogących mieć wpływ na zmianę zakresu projektu. Osoby niezwiązane z techniką często przeciwko nim protestują, jednak dostawca, który ulegnie tym sprzeciwom, powinien przygotować się na formułowanie przez zamawiającego nierealnych wymagań, a zwłaszcza presji na błyskawiczne wykonanie projektu. W praktyce nadmierny pośpiech powoduje jednak tak dużą liczbę błędów, że w efekcie czas realizacji projektu wydłuża się.

Znając krytyczny poziom wydajności zespołu projektowego możemy skutecznie renegocjować warunki realizacji (zakres i czas) projektu. Ilościowe prezentacje zależności pomiędzy liczbą i jakością błędów a tempem pracy pokazują zlecającemu, ze zbytnie naciskanie na zwiększenie wydajności przez wykonawcę przynosi skutek odwrotny do zamierzonego - powiedział Bogusław Machowski.

Wieloletnie projekty charakteryzuje również etapowość. Złożone systemy tworzy się wg modelu kaskadowego, aby uniknąć dodatkowego ryzyka, związanego z zastosowaniem nowszych koncepcji. Przy czym plany testów są tworzone równolegle do tworzenia samych systemów, a nawet analizy. Pomiędzy poszczególnymi etapami znajdują się tzw. bramki jakości. Dokonuje się wówczas przeglądu dokumentacji, kodu, testów wewnętrznych. To pozwala panować nad błędami nie tylko w sensie jakościowym, ale także ilościowym. Do tego niezbędna jest również ilościowa ocena poprawności i wydajności działani. Błędy kategoryzuje się wg stopnia ich wpływu na jakość całego systemu.