Kurs Programowania CTS

Kurs PHP, kurs HTML/CSS, VBA, JavaScript, T-SQL

Menu

Dylemat: planowanie, czy metoda prób i błędów?

Czy można zbudować oprogramowanie, nie znając wymagań, czyli nie wiedząc, co tworzony program ma robić? Oczywiście, nie można, tak jak nie da się zaprojektować ani wyprodukować nowego modelu samochodu, nie wiedząc, czy potrzebne jest auto wyścigowe, rodzinne kombi, czy ciężarówka.
Proces zdobywania tej wiedzy, określania celu przedsięwzięcia IT, bywa różnie nazywany. Klasyczny termin inżynierii wymagań, to pozyskiwanie wymagań, ale spotyka się też wiele innych nazw.

W modelach sekwencyjnych tworzenia oprogramowania przyjmuje się założenie, że pozyskiwanie wymagań jest pierwszą fazą każdego projektu, że dopiero znalazłszy i zdefiniowawszy wszystkie wymagania, można przystępować do kolejnych etapów tworzenia systemu. Takie założenie jest intuicyjnie bardzo sensowne. Nie wiedząc, co właściwie jest celem przedsięwzięcia, ryzykuje się przecież pracę na chybił-trafił, konieczność kosztownych przeróbek, czy nawet rozpoczynania wszystkiego od początku. Nie znając wymagań, nie da się ani określić pracochłonności i kosztów projektu, ani jego statusu: co już zrobiono, co pozostało jeszcze do zrobienia.

Tę tezę opisuje tak zwana krzywa Boehma, ilustrująca prostą zależność, że koszt zmiany jest tym większy, im później w cyklu życia (wytwarzania) produktu zmiana zostanie dokonana.
Prawdziwość zależności ilustrowanej krzywą Boehma jest dobrze potwierdzona wieloma obserwacjami i nawet badaniami. Wynika z niej, że aby zminimalizować koszty i pracochłonność projektu, należy wszystkie wymagania określić precyzyjnie już od początku, a dopiero potem przystąpić do kolejnych etapów, do wytwarzania systemu.

Krzywa Boehma wskazuje, że taniej jest zapobiegać, niż leczyć, że nagminne w branży informatycznej pomijanie pracy z wymaganiami na rzecz jak najszybszego przystąpienia do tworzenia kodu, bywa podejściem nieskutecznym i na dłuższą metę kosztownym – nawet katastrofalnie kosztownym.
Jednak przy podejmowaniu decyzji projektowych i biznesowych koszty zmian nie są jedynym kryterium. Inne, ważne kryterium to przede wszystkim koszt, czy wręcz możliwość, zdobycia niezbędnej dla uniknięcia zmian wiedzy już na początku przedsięwzięcia.

Koszt pozyskania wszystkich wymagań na samym początku projektu, choć niewątpliwie pozwala uniknąć kosztów związanych z późniejszą zmianą i samych wymagań, i realizującego je kodu, może być znaczny. W szczególności, pozyskanie wszystkich wymagań może być wręcz niemożliwe. Próba realizacji modelu sekwencyjnego za wszelką cenę, ignorowanie innych – poza kosztem zmian – czynników kosztów projektu – powoduje wiele negatywnych skutków:

Ryzyko 1 – tworzenie błędnych wymagań

Tworzenie błędnych wymagań – kiedy analitycy / inżynierowie wymagań są pod presją, aby za wszelką cenę dostarczyć jakieś wymagania, a nie mają po temu możliwości, z dużym prawdopodobieństwem dostarczą jakieś wymagania – dobrze wyglądające, ale niepoprawne.

Ryzyko 2 – przyjmowanie fałszywych założeń

Przyjmowanie fałszywych założeń – przyjęcie założenia o tym, że obecne potrzeby klienta lub wymagania rynku nie ulegną w przyszłości zmianie – pozwala wprawdzie na sformułowanie wymagań poprawnych w chwili, gdy się je definiuje, ale być może nieprawdziwych w przyszłości, w chwili, gdy dostarczony będzie produkt, zbudowany na ich podstawie.

Ryzyko 3 – opóźnienie

Opóźnienie – wstrzymywanie innych działań, w tym programowania, aż do momentu zdobycia pełnych wymagań – powoduje, że produkt budowany według filozofii sekwencyjnej wchodzi na rynek później, niż produkt konkurencyjny, co może być przyczyną konkurencyjnej porażki, nawet jeśli produkt późniejszy będzie lepszy pod względem niektórych atrybutów jakości.

Ryzyko 4 – pomijanie priorytetów

Pomijanie priorytetów – nie wszystkie wymagania są jednakowo ważne ani pilne i te najważniejsze / najpilniejsze można często z korzyścią zacząć realizować, zanim uda się uzyskać pełny obraz i opis pozostałych wymagań.

Ryzyko 5 – pełzające wymagania

Zagrożenie pełzających wymagań – w sytuacji, kiedy koszt zdefiniowania i zapisania wymagania, to ledwo kilka minut, a koszt jego realizacji – wiele osobodni, łatwo, zwłaszcza klientowi, o pewną rozrzutność, wymyślanie wymagań, które tak naprawdę nie są mu dostatecznie potrzebne. Aby tego uniknąć, warto jest często przerwać proces pozyskiwania wymagań i przystąpić do realizacji już zdefiniowanych, zamiast szukać dalszych.

Ryzyko 6 – rezygnacja z dostaw częściowych

Rezygnacja z dostaw częściowych z powodu oczekiwania na pełny obraz wymagań, oznacza rezygnację z opcji dostaw przyrostowych, co oznacza straty.

Ryzyko 7 – rezygnacja z korzyści prototypowania

Określenie wymagań wobec produktu IT jest trudnym wyzwaniem intelektualnym i poznawczym – niełatwo jest z góry wyobrazić sobie wszystkie swoje potrzeby, ich obecne i przyszłe priorytety. W praktyce niekiedy cel biznesowy projektu IT – jego wizja i misja w języku inżynierii wymagań – określany jest jednocześnie z podejmowaniem próby modelowania i optymalizacji procesu biznesowego, co dodatkowo utrudnia pozyskanie wszystkich wymagań od początku. W tej sytuacji, różnego rodzaju prototypy funkcjonalności, interfejsu lub współdziałania systemu IT z procesem biznesowym mogą to zadanie ułatwić.