Metodyka inżynierii wymagań

Realizacja zadań w pierwszym etapie projektu "Modernizacja systemów in-formatycznych do obsługi egzaminów zewnętrznych i nadzoru pedagogiczne-go" nakładała konieczność zastosowania szeregu metod inżynierii wymagań:

analizę ekspercką (analizę istniejących systemów w połączeniu z badaniem interoperacyjności za pomocą wzorca); wywiady z ekspertami i użytkownikami (w połączeniu z zastosowaniem ustrukturyzowanego opisu wymagań oraz an-kiet), prototypowanie oraz zastosowanie analizy użyteczności. Podział ten wy-nikał z określonych uwarunkowań i motywacji a każda z metod posiadała swoje zalety i wady. Przed rozpoczęciem prac dokonano ewaluacji zastosowanych metod inżynierii oprogramowania w odniesieniu do warunków projektu i zało-żonych celów. Poniższy rozdział zawiera podsumowanie przeprowadzonej ewa-luacji.

4.2.1 Analiza ekspercka

Analiza ekspercka uzasadniona jest wtedy, jeżeli istnieje konieczność do-głębnego badania technicznego systemu informatycznego (np. w przypadku próby określenia jego bezpieczeństwa, wydajności, możliwości integracji).

Z uwagi na dużą czasochłonność i kosztowność analizy eksperckiej, powinna być ona stosowana tylko do niewielkiej liczby krytycznych systemów. Analiza ekspercka pozwala na uzyskanie wyników (przede wszystkim wymagań nie-funkcjonalnych) o bardzo wysokiej jakości. W projekcie będącym tematem niniejszego rozdziału, analiza ekspercka została zastosowana w przypadku jed-nego, kluczowego systemu, jakim był system SIO.

Analiza ekspercka wymaga dostępu do kodu źródłowego oraz do statystyk środowiska produkcyjnego (np. obciążenie serwera aplikacji, obciążenie serwe-ra bazy danych, itp. Sporym ułatwieniem na każdym, nie tylko początkowym, etapie pracy jest dostępność i możliwość konsultacji z wykonawcami badanego systemu. Naturalnym jest, że analiza ekspercka, będąca swego rodzaju audytem, jest analizą krytyczną. Niedostateczne umotywowanie wniosków czy nieodpo-wiednio dobrane przykłady, mogą stać się zarzewiem rozbieżności, czy wręcz konfrontacji, pomiędzy analitykami a aktualnym wykonawcą

4.2.2 Wywiady z użytkownikami

Wywiady zapewniają możliwość bezpośredniego spotkania i rozmowy z rzeczywistymi użytkownikami systemu informatycznego. Dzięki dynamice takiego spotkania (przede wszystkim możliwość eksploracji wybranych

obsza-Inżynieria wymagań w modernizacji systemów informatycznych na przykładzie… 99 rów problemu, moderowania dyskusji i odbiegania od przyjętego skryptu czy szablonu) możliwe jest poznanie potrzeb użytkownika, które są trudne do na-zwania i opisania (np. motywacje, przyzwyczajenia, subiektywne odczucia, uprzedzenia, itp.). Z drugiej strony spotkania takie są czasochłonne, zarówno z uwagi na czas trwania spotkania jak i na kosztowność opracowania wyników.

Komfortową sytuacją jest możliwość przeprowadzenia wielokrotnych wywia-dów z użytkownikiem, analiza i ewentualna redefinicja wcześniej zebranych wymagań. W takim przypadku minimalizuje się prawdopodobieństwo niezro-zumienia lub niewłaściwej interpretacji wymagań użytkownika.

Bezpośrednie spotkanie z użytkownikiem w miejscu jego pracy daje również możliwość podejrzenia narzędzi, z których na co dzień on korzysta, organizacji pracy oraz charakterystyki użytkowanych urządzeń końcowych (np. wielkość monitora, szybkość łącza internetowego). Informacje te są niedocenionym źró-dłem wymagań niefunkcjonalnych, których zdefiniowanie jest często dla użyt-kownika nieoczywiste.

Bezpośrednie wywiady z użytkownikami pozwalają na uzyskanie dużej licz-by wymagań, zatem powinny licz-być stosowane, gdy liczba użytkowników nie jest duża, lub gdy spośród wszystkich użytkowników można wyselekcjonować re-prezentatywną grupę.

4.2.3 Ankiety

W przeciwieństwie do zbierania wymagań podczas bezpośrednich spotkań z użytkownikami, skorzystanie z ankiet nie zapewnia interakcji i nie pozwala na pozyskanie dodatkowej wiedzy (np. motywacji, przyzwyczajeń czy też subiek-tywnych odczuć). Z drugiej jednak strony możliwe jest zebranie wymagań od bardzo dużej liczby ankietowanych. Zamknięta formuła tej metody ułatwia opracowywanie wyników. W zależności od zastosowanej metodyki (ankiety drukowane, ankiety online) możliwa jest automatyczna analiza wyników, wraz z wygenerowaniem statystyk. Brak bezpośredniego kontaktu z użytkownikiem pociąga za sobą brak możliwości wyjaśnienia wątpliwości w przypadku niezro-zumienia pytania przez ankietowanego.

Przygotowanie dobrej ankiety wymaga od autora uwagi i zaangażowania.

Szczególny nacisk należy położyć na opracowanie spójnej i jednoznacznej ter-minologii. Warto również, aby pierwsza wersja ankiety została wypełniona przez wybraną, zwykle małą, grupę użytkowników. Na podstawie doświadczeń zebranych w małej próbie, można do ankiety wprowadzić wymagane poprawki.

Szerokiemu gronu użytkowników zaprezentować należy poprawioną wersję ankiety.

100 Inżynieria oprogramowania – badania i praktyka

Skorzystanie z ankiet jest zatem metodą oszczędzającą czas i koszty zebrania wymagań, lecz potencjalnie może mieć negatywny wpływ na jakość wyników.

Należy również położyć odpowiednio duży nacisk na formę ankiety i jej złożo-ność, tak aby w rezultacie uzyskać oczekiwany obraz wymagań użytkowników.

4.2.4 Ustrukturyzowany opis wymagań

Ustrukturyzowany opis wymagań zakłada, że użytkownicy przekazują wy-magania w ujednoliconej, spisanej formie. Zwinne metodyki wytwarzania opro-gramowania [COH04] zalecają, żeby opis taki miał formę tzw. historii użyt-kownika (ang. user stories). Każda z historii składa się z trzech części:

⎯ użytkownik,

⎯ czynność,

⎯ wartość biznesowa.

W uproszczeniu, historię użytkownika można przedstawić jako wypowiedź typu: „Jako użytkownik chciałbym móc wykonać czynność, aby osiągnąć zało-żony cel”. Opcjonalnie, każda historia użytkownika może zawierać tzw. kryteria akceptacyjne. Przykładem historii użytkownika byłaby zatem wypowiedź: „Ja-ko dyrektor sz„Ja-koły chciałbym mieć możliwość wydru„Ja-kowania listy zdających, aby sprawdzić obecność na egzaminie.”

Uznaje się, że najważniejszą częścią historii użytkownika jest wartość bizne-sowa, gdyż to zbiór wartości biznesowych formułuje listę pożądanych funkcjo-nalności. Tworzenie ustrukturyzowanych opisów wymagań w formie historii użytkownika wymaga dużego zaangażowania ze strony tegoż użytkownika.

W rezultacie minimalizuje się jednak prawdopodobieństwo otrzymania nie-przemyślanego czy zbędnego wymagania. W przypadku dużej liczby użytkow-ników znacząco może wzrosnąć koszt analizy zgłoszonych wymagań (z uwagi chociażby na potencjalnie powielające się historie).

Korzystanie z ustrukturyzowanego opisu wymaga od użytkownika doświad-czenia w formalnej definicji wymagań dla systemu i chęci zaangażowania w ten proces. Można tę metodę włączyć do wywiadu z użytkownikiem, co pozwoli na uzyskanie jeszcze lepszych rezultatów (zwiększając jednocześnie czaso-chłonność). W pożądanym przypadku, docelowa grupa odbiorców systemu ma doświadczenie w wypełnianiu dokumentów z opisem wymagań a ponadto po-trafi zdefiniować kryteria akceptacyjne. Wówczas zebrane wymagania stanowią doskonałe wejście do rozpoczęcia prac programistycznych w ramach zwinnej metodyki, gdzie zdefiniowane przez użytkowników historie można łatwo roz-dzielić na zadania programistyczne.

Inżynieria wymagań w modernizacji systemów informatycznych na przykładzie… 101 4.2.5 Prototypowanie

Prototypowanie zakłada wielokrotne tworzenie nowych wersji oprogramo-wania (ale również innego dowolnego produktu) w celu zaprezentooprogramo-wania go użytkownikom i uzyskania natychmiastowej weryfikacji wymagań i założeń projektowych. Prototypowanie stwarza możliwość bezpośredniej, iteracyjnej i przyrostowej pracy z użytkownikami znacznie minimalizując ryzyko niezro-zumienia ich oczekiwań. Inną wartością jest możliwość uzyskania dodatkowych wymagań i zgłoszeń nieprawidłowości na wczesnym etapie projektu.

Prototypowanie pociąga jednak za sobą zwiększony koszt fazy zbierania wymagań (wynikający z konieczności zatrudnienia programistów już na wcze-snym etapie projektu). Bez wątpienia jednak umożliwia zebranie bardzo szcze-gółowych wymagań dodatkowo dostarczając ich wstępnej weryfikacji.

W przypadku projektów informatycznych, prototypowanie ograniczyć moż-na do zbudowania makiety interfejsu użytkownika. Makieta ta powinmoż-na ukazy-wać możliwości docelowego systemu, odwzorowyukazy-wać układ graficzny i pozwa-lać na interakcję umożliwiającą symulację przeprowadzenia czynności, które wspierane będą przez docelowy system.

4.2.6 Analiza użyteczności prototypu

Analiza użyteczności prowadzona jest podczas prezentacji użytkownikom kolejnych wersji prototypu i polega na obserwacji następujących elementów:

reakcje (gesty, mimika) użytkownika, komentarze użytkownika wypowiadane podczas interakcji z prototypem, sekwencje działań podejmowanych przez użytkownika w celu wykonania zadania, czas potrzebny na wykonanie zadania oraz analiza ruchu gałek ocznych (ang. eye tracking). W celu dokładnego opra-cowania wyników zaleca się rejestrację sesji testowej, czyli zarejestrowanie twarzy użytkownika, wypowiadanych komentarzy oraz zdarzeń prezentowa-nych na ekranie

Analizę użyteczności można wspomagać za pomocą urządzenia zwanego okulografem (ang. eye-tracker). Okulograf pozwala na śledzenie ruchu gałek ocznych, co w rezultacie daje możliwość analizy ścieżek wzroku (ang. scan paths) oraz tzw. map termicznych (ang. heat maps). Analiza ścieżek wzroku pozwala na odtworzenie kolejności przeglądania elementów interfejsu użyt-kownika, natomiast mapy termiczne pozwalają na określenie czasu, przez jaki badany patrzył na poszczególne elementy interfejsu użytkownika. Warto pod-kreślić, że analiza użyteczności wykonana przy użyciu okulografu powinna być połączona z pozostałymi informacjami zebranymi w toku badania, jak

komenta-102 Inżynieria oprogramowania – badania i praktyka

rze i pytania badanego czy notatki nadzorującego testy. Inaczej wyniki takiego badania mogą okazać mało wartościowe.

Analiza użyteczności zwiększa koszt fazy zbierania wymagań, pośrednio (tzn. po przeprowadzeniu interpretacji rezultatów) dostarczając nowych wyma-gań niefunkcjonalnych, które mogą mieć znaczący wpływ na intuicyjność ko-rzystania z systemu.

4.3 Inżynieria wymagań w projekcie