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  

# Problem klienta nie znającego UMLKuba 2009-05-21 09:57
Szymon, Zupełnie się z Tobą nie zgadzam :-) Sytuacja, o której piszesz, czyli analiza "zatwierdzona" przez klienta bez zrozumienia, nie jest mi obca. Z perspektywy czasu widzę jednak, że problemem nie jest klient, który nie czyta albo nie rozumie diagramów. Ani klient, który nie ma wizji. Problemem jest założenie, że możliwe jest przewidzenie dzisiaj jak powinien wyglądać system, którego będzie się używać za rok. Zgadzam się z tym, że klient musi rozumieć to, co ma zatwierdzać. Inaczej efektem jest fałszywe poczucie bezpieczeństwa (u dostawcy) i strach albo obojętność (u klienta). Ja bym bardziej stawiał na prostotę materiałów, na których pracuje się z klientem, niż na uczenie go UML'a. Tak czy inaczej, ważne jest jednak, żeby mieć wspólny język. To jednak nie wystarczy. Nie wiem ile trwał Wasz projekt dla telecom'u, ale strzelam, że gdyby czas od analizy do testów był krótszy i klient bardzo szybko testowałby kawałek aplikacji, który "przed chwilą" był analizowany (przy aktywnym udziale klienta), to nie byłoby problemu, o którym napisałeś. Co prawda z takim podejściem są inne problemy, ale to zupełnie inny temat, który chętnie poruszę, jeżeli napiszesz stosowny artykuł ;-) Tak więc moim zdaniem nauczenie klienta UML'a rozwiązuje jakiś problem (chociaż można go chyba rozwiązać prościej), ale nie jest to problem zasadniczy. Nawet jeżeli ktoś zatwierdzi stertę diagramów, dokładnie wiedząc co zatwierdza, to nie da to jeszcze gwarancji, że będzie zadowolony z systemu powstałego na podstawie tej sterty.
Odpowiedz
# Czego potrzebuje klient?Tomek 2009-05-21 20:49
Szymon, na pewno takie działanie kosztowało wiele cierpliwości:)? Przed rozpoczęciem prac analitycznych odpowiednie wydaje mi się m.in.: 1. uświadomienie klienta jakich artefaktów ma się spodziewać, 2. przeprowadzenie szkoleń jeśli istnieje obawa, że klient nie będzie w stanie czegoś zrozumieć. Powszechnie stosowana w projektach informatycznych spychologia nie służy niczemu dobremu. Klient otrzymuje do weryfikacji i akceptacji dokumentację techniczną, która jest mu zupełnie obca i...rozpoczyna się walka. Pytanie czy klient potrzebuje modelu klas? Może jeszcze inaczej, czego potrzebuje klient - jeśli chodzi o analizę?
Odpowiedz
# A może use case'y?joanna 2010-10-24 18:57
"Podstawowy wytwór prac analityków, czyli diagramy obrazujące poszczególne aspekty systemu (w tym najważniejsze ze wszystkich - diagramy klas)"
Odpowiedz
# A może use case'y?joanna 2010-10-24 18:59
Piszę jeszcze raz bo w poprzedniej próbie zjadło mi pół posta 'Podstawowy wytwór prac analityków, czyli diagramy obrazujące poszczególne aspekty systemu (w tym najważniejsze ze wszystkich - diagramy klas)' - dziwna ta analiza, skoro jest podstawą są diagramy klas. Ludzie zdecydowanie za mocno trzymają się diagramów klas.. Ja polecałabym się skupić na wysokopoziomowych use case'ach opisywanych tekstem (bez diagramów! a przynajmniej nie do wglądu dla klienta) i ujęciu reguł biznesowych w jakieś ładne tabelki.
Odpowiedz

Dodaj komentarz