Powszechna sytuacja: dostawca realizuje dla klienta system "szyty na miarę". Wyniki analizy dostarcza m. in. w postaci dlagramów np. w języku UML. Tymczasem przedstawiciele klienta to specjaliści biznesowi, a nie informatycy. Nie znają więc notacji UML. Jak sprawić, żeby zrozumieli model i zaczęli się z nim identyfikować? Pełniąc rolę głównego analityka w projekcie realizowanym dla instytucji ubezpieczeniowej, zastosowałem w tym celu ciekawą technikę.
Klient podpisuje z dostawcą umowę na wdrożenie systemu informatycznego. Wcześniej dostawca na podstawie lepiej lub gorzej określonych wymagań oszacował pracochłonność i cenę. Teraz obie strony pełne entuzjazmu przystępują do fazy analizy. Analitycy dostawcy spotykają się ze specjalistami klienta, uszczególawiając wymagania i tworząc model przyszłego systemu. Piszą specyfikacje i rysują diagramy np. w języku UML. Na koniec wszystkie produkty fazy analizy przekazują klientowi do akceptacji.
Byłoby idealnie, gdyby po stronie klienta była osoba mająca wizję przyszłego systemu i odpowiednie przygotowanie informatyczne, w szczególności znająca i rozumiejąca użytą notację graficzną. Taka sytuacja to jednak rzadkość. Często ze strony klienta w projekcie uczestniczą tylko specjaliści dziedzinowi nie mający obycia informatycznego. Świadomie zaakceptują oni tylko te fragmenty analizy, które będą w stanie zrozumieć. Podstawowy wytwór prac analityków, czyli diagramy obrazujące poszczególne aspekty systemu (w tym najważniejsze ze wszystkich - diagramy klas) pozostaną niezweryfikowane przez klienta. Efekty ewentualnych błędów - szczególnie wmodelu klas, który jest podstawą implementacji logiki biznesowej - będą uprzykrzały życie obu stronom i będą trudne do zlikwidowania w chwili, gdy system będzie gotowy.
Czy można uniknąć takiej sytuacji lub choćby zminimalizować ryzyko jej wystąpienia? W jednym z projektów, w którym pełniłem rolę głównego analityka, postanowiliśmy spróbować ciekawej, choć dość prostej metody: wspólnego czytania diagramów klas wraz z przedstawicielami klienta. W końcowej fazie prac analitycznych, gdy model klas był już prawie gotowy, lecz jeszcze przed przekazaniem analizy do akceptacji, organizowaliśmy spotkania, podczas których prezentowaliśmy uczestnikom na ekranie model dziedziny (diagram klas). Jego omawianie nie było jednak głównym tematem spotkania. Rozmawialiśmy o tym, w jaki sposób proces biznesowy będzie wspierany przez system i dyskutowaliśmy nad funkcjonalnością systemu. Podczas rozmowy np. o rejestrowaniu szkody ubezpieczeniowej pokazywałem odpowiedni fragment diagramu klas i czytałem jego zawartość, np. "tu jest narysowane, że w zdarzeniu może uczestniczyć wiele pojazdów, ale musi być co najmniej jeden; nie można zarejestrować szkody bez żadnego pojazdu", pokazując jednocześnie odpowiednie klasy, relacje i liczności. Przedstawiciele klienta weryfikowali te stwierdzenia, potwierdzając ich poprawność lub opowiadając o sytuacjach, gdy przyjęty model jest niepoprawny. Po kilku takich próbach przedstawiciele klienta na tyle przyswoili sobie podstawy notacji, że zaczęli sami odczytywać zawartość diagramu i upewniać się, że dobrze ją rozumieją. Mimo że ani my, ani nikt inny wcześniej nie uczył ich notacji UML, dość szybko zaangażowali się w weryfikowanie modelu.
Podczas tak prowadzonych sesji analitycznych udało się wykryć i poprawić kilka istotnych usterek modelu, wynikających z niepełnego zrozumienia biznesowego świata klienta przez nas - analityków dostawcy. Nie sądzę wprawdzie, aby po oficjalnym przekazaniu analizy do akceptacji klient pieczołowicie weryfikował diagramy, ale jestem przekonany, że dzięki wspólnemu czytaniu diagramów znacznie ograniczyliśmy ryzyko rozminięcia się analizy (a więc i stworzonego na jej podstawie systemu) z rzeczywistością.
Nie zawsze jednak można sobie pozwolić na takie sesje analityczne. W kolejnym projekcie, w którym brałem udział - tym razem dla firmy telekomunikacyjnej - napięte terminy nie pozwoliły na organizowanie tego rodzaju spotkań. Pełna analiza, wraz z diagramami klas, bezpośrednio po przygotowaniu i wewnętrznej weryfikacji, została przekazana do klienta, który oczywiście nie był w stanie zweryfikować poprawności modelu dziedziny. Klika istotnych braków nie zostało wykrytych ani w produktach fazy analizy, ani nawet w scenariuszach testów akceptacyjnych. Przedstawiciele klienta zwrócili na nie uwagę dopiero podczas testów systemu. Cóż, w takiej sytuacji jedynym ratunkiem mogą okazać się zdolności negocjacyjne kierownika projektu i dobra wola klienta...
Szymon Zioło
Komentarze