Nie wiem czego chcę, ale jak to zobaczę, powiem, czy to jest to

Przeprowadzenie analizy wymagań w praktyce nie przyniesie zadowalających efektów, jeżeli użytkownik nie będzie mógł zobaczyć, jak system będzie wyglądał i działał przed przystąpieniem do szczegółowego projektowania. Ludzka wyobraźnia ma określone granice. Nie tylko projektant nie wie na początku, co to będzie za system. Bardzo rzadko także użytkownik dokładnie wie, czego chce. Wyobraźmy sobie, że zamierzamy zbudować dom. Na początku musimy wybrać się do architekta, który wykonana dla nas projekt. Nawet jeśli mamy dokładną wizję naszego domu, to i tak w rozmowach z architektem okaże się, że wejście do toalety nie może być na wprost wejścia do domu, komin jest za niski, i tak dalej. Architekt po wysłuchaniu naszych wymagań przedstawi nam kilka szkiców, my zgłosimy nasze uwagi, architekt narysuje nowy, aż wreszcie powstanie projekt domu, być może zupełnie inny niż nasze pierwotne wizje rozwiązań, ale za to dokładnie taki, jaki chcemy i możemy zbudować.

Podobnie możemy projektować system. Definiowanie wymagań warto doprowadzić do fazy prototypowania. Analiza wymagań jest bardzo potrzebna, ale niewystarczająca.

Czym jest i czym nie jest prototypowanie

Najczęściej prototypowanie zaczynamy od zdefiniowania zadań użytkownika, wspólnie przez projektantów i użytkowników. Definiując zadania opisujemy scenariusze typowych postępowań użytkownika z przyszłym systemem. Otrzymujemy w ten sposób opis zadań, który z jednej strony jest zrozumiały dla użytkownika, z drugiej, daje projektantom lepsze zrozumienie potrzeb klienta.

Następnie na podstawie zadań budujemy prototyp aplikacji. Pierwsza wersja prototypu może powstać tylko na papierze, w czasie sesji JAD poświęconej zaprojektowaniu interfejsu użytkownika.Wspólnie z użytkownikiem rysujemy przyszłe okna aplikacji i przykłady raportów.

Mając opis zadań i papierowy prototyp, możemy przystąpić do budowy drugiej wersji prototypu, wykorzystując pewne narzędzie do budowy aplikacji. Najpierw jednak trzeba wybrać właściwe narzędzie.

Często do prototypowania wybieramy docelowe narzędzie, którym będzie budowany system. Z reguły nie jest to konieczne. System zapewne musi być zbudowany z wykorzystaniem zaawansowanej, często trudnej technologii, prototyp możemy za to zbudować czymkolwiek. Wystarczy w tym celu użyć jakiegokolwiek składacza ekranów. Prototyp nie musi działać jak docelowy system, wystarczy, że będzie podobnie wyglądał.

W praktyce prototyp do przeciętnej wielkości aplikacji jest budowany przez 1-3 dni, przez 1-3 osoby. W przypadku dużych systemów powinniśmy projekt podzielić na kilka przyrostów (części lub modułów), tak więc rzadko kiedy budowa prototypu jest bardziej pracochłonna.

Zbudowany prototyp powinien być zweryfikowany przez użytkownika. Naturalnym sposobem weryfikacji jest sprawdzenie, czy prototyp umożliwia wykonanie zdefiniowanych wcześniej zadań użytkownika. Wracając do przykładu z architektem, projektanci kilka razy poprawiają i weryfikują z użytkownikiem prototyp do momentu, aż użytkownik zaakceptuje wizję przyszłego systemu, podobnie jak architekt poprawia szkice do czasu, aż narysuje dom naszych marzeń.

Prototypowanie jest niczym innym jak ewolucyjnym sposobem na zbieranie wymagań. Tworząc prototyp tanim kosztem, możemy zweryfikować wspólnie z użytkownikiem nasze wyobrażenia dotyczące przyszłego systemu. Użytkownik uczestnicząc w sesji prototypowania może zobaczyć, jak jego wymagania będą zrealizowane w praktyce. Jedne rozwiązania są akceptowane, inne nie, do niektórych rozwiązań użytkownik zgłasza poprawki. Bardzo często użytkownik wspólnie z projektantem wymyśla nowe rozwiązania lub stawia nowe wymagania, o których wcześniej nie pomyślał. W projektach, w których uczestniczyłem, sesje prototypowania zawsze bardzo angażowały projektantów i użytkowników. Jest to jeden z tych momentów w projekcie, które dają ogromną satysfakcję obu stronom z tworzenia czegoś nowego, tym bardziej że efekty są natychmiast widoczne.

Totalnym nieporozumieniem jest wymyślanie prototypu przez projektanta. Siada on przy komputerze, wymyśla okienka, menu, wydruki, realizując wizję systemu, którą następnie przedstawia użytkownikowi. Co więcej, ma potem pretensje do użytkownika, że prototyp mu się nie podoba i nie docenia jego wspaniałego pomysłu. Prototyp, podobnie jak specyfikacje, powinien być tworzony wspólnie z użytkownikiem, a nie zamiast niego. W przeciwnym razie użytkownik zamiast być naszym partnerem i sprzymierzeńcem będzie nieufnym i nieprzychylnym nam klientem.

Podsumowanie

Budowanie systemów informatycznych jest zadaniem skomplikowanym, które łączy precyzyjne działania inżynierskie z innowacją czy wręcz "artystyczną twórczością". Często, niestety, twórcy systemów zapominają, że systemy, które budują, ktoś u nich zamówił i chce ich do czegoś używać. Zmieszczenie się w zadanym budżecie i harmonogramie jest niewątpliwym sukcesem. Realizacja wszystkich zaplanowanych funkcji również jest powodem do chwały. Najważniejsza jest jednak satysfakcja użytkownika, który może być zadowolony z mniejszego i droższego systemu niż zaplanowany, pod warunkiem że jest przekonany o tym, iż to, co otrzymał, jest tym, czego oczekiwał.

<hr size=1 noshade>Robert Kulicki jest zastępcą dyrektora ds. konsultacji InfoViDE.