Wstęp

Wśród wielu znanych i stosowanych sposobów dokumentowania wymagań na systemy są tekstowe i tabelaryczne opisy oraz metody formalne. Pierwsze są tak niejednoznaczne, że są źródłem wielu problemów drugie tak kosztowne i niezrozumiałe dla „laików”, że w zasadzie nie stosowane. Pośrodku mamy metody „półformalne” czyli modele. Ich cechą jest duża jednoznaczność wymagają jednak pewnego minimalnego obycia z diagramami u ich czytelnika oraz dużych umiejętności u twórcy. często powtarzam swoim studentom: dobry model jest jak wiersz: dużą sztuką jest jego napisanie ale do przeczytania powinna wystarczyć znajomość alfabetu. W tym artykule, adresowanym do każdego kto spotyka się lub wie, że go to spotka, z analizami wymagań i ich dokumentowaniem za pomocą diagramów. Zwrócę także uwagę na typowe problemy i ryzyka związane ze stosowaniem popularnych metodyk i notacji.

Napisze kilka słów adresowanych głównie do nabywców systemów. Powiem na co zwracać uwagę w dokumentacjach wymagań i czego raczej nie robić samemu. Cała dokumentacja wymagań opisuje to jaki ma być przyszłe oprogramowanie jednak kluczem do jej skuteczności jest opis biznesowy organizacji i jej zrozumienie czyli zrozumiały dla wszystkich uczestników projektu model biznesowy i wskazany na nim zakres projektu. Jest to najczęściej pomijany element projektu przez dostawców systemów. Dlaczego? Zaryzykuje tezę: dostawcy systemów to dobrzy inżynierowie, którzy z reguły nie mają wiedzy i doświadczenia z zakresu marketingu i zarządzania jednak angażowani są w tworzenie narzędzi do wspomagania zarządzania. Źródłem wielu problemów projektów IT jest luka komunikacyjna pomiędzy biznesem a inżynierią oprogramowania. Podobno powszechnie o tym wiadomo a jednak nadal wiele dokumentacji wymagań pozostawia wiele do życzenia. Dlaczego?

O tym jak przypadki użycia rodzą kłopoty

Obserwuję dwa rodzaje różnych podejść do analizy i dokumentowania wymagań: opisy testowe i strukturalne w przypadku planowanego zakupu gotowego systemu oraz metody zorientowane na przypadki użycia w projektach budowania systemów „od zera” (tak zwanych dedykowanych). Pierwsze, opisowe, są od dawna uznane za złe więc nie będę się nad nimi tu rozwodził i generalnie odradzam ich stosowanie. Metody zorientowane na przypadki użycia są coraz częściej uznawane za niekompletne gdyż zatracają biznesowy kontekst projektu zaś same przypadki użycia nic nie mówią o tak zwanych aspektach użycia systemu, jego służebnej roli w procesach biznesowych (mowa tu o systemach wspomagających zarządzanie i pokrewnych). Do tego przypadki użycia są z reguły tworzone z udziałem szeregowych pracowników, przyszłych użytkowników systemu Ci zaś nie dość, że najczęściej nie mają pojęcia o całościowej strategii firmy to z reguły podają informacje służące ich partykularnemu chwilowemu interesowi a nie interesowi całej organizacji.

RUP

Jedną z najczęściej spotykanych w firmach developerskich metodyk analizy i projektowania jest Rational Unified Proces (RUP). Jest to typowy reprezentant metodyk zorientowanych na przypadki użycia i opisuje jedynie ogólne zasady tworzenia obiektowego modelu systemu jakim jest także dana organizacja. Metodyka ta bazuje na notacji UML (Unified Modeling Language) ta zaś wspiera praktycznie tylko obiektowe metody analizy i projektowania systemu a nie samej organizacji. UML nie zawiera notacji (typ diagramu) pozwalającej skutecznie modelować organizacje w paradygmacie procesowym. Diagram czynności w UML stanowi ledwie namiastkę potrzebnych możliwości zaś jego rolą jest tak na prawdę modelowanie algorytmów funkcji (metod obiektów). Nawet podręczniki RUP’a odwołują się do innych notacji takich jak eEPC czy od pewnego czasu BPMN (żr. UML 2.0 w akcji, podręcznik oparty na projektach i inne książki o RUP). Jeżeli coś nowego pojawiło się w RUP w kwestii tworzenia modeli organizacji chętnie poznam tytuł i autora książki.

O językach i teorii komunikacji

Niedawno ukazała się ciekawa książka (Inżynieria systemów informacyjnych, Paul Beynon-Davies), opisuje w dość przystępny sposób dawno znaną z teorii komunikacji społecznej kwestię kontekstu i odbioru modelu. Błędy w tej materii są postrzegane, nie tylko przeze mnie, jako podstawowe źródło kłopotów w projektach IT. Uogólniając nie ma znaczenia czy dany model jest wykonany poprawnie od strony syntaktycznej (czy poprawnie połączono symbole) i semantycznej (czy użyto właściwych symboli) w tej czy innej notacji. Znaczenie ma to, czy adresat poprawnie i jednoznacznie go zrozumiał (semiotyka modelu – to jak znaki zostały odebrane i zrozumiane przez obserwatora) i nic innego się nie liczy.

Model ma dwa zadania w analizie: symulacja rzeczywistej organizacji dla analityka i projektanta oraz udokumentowanie decyzji organizacyjnych dla menedżerów. Ten drugi cel jest z reguły zaniedbywany i w efekcie menedżerowie zamawiający system często podpisują dokumentacje, których tak na prawdę nie rozumieją pod wpływem sugestii (a bywa, że perswazji!) pseudoanalityków dostawcy systemu, że nie muszą tego rozumieć ale muszą podpisać bo to wymóg projektu. Nic bardziej błędnego!

Istotą opisu wymagań na system jest kontekst całego projektu i tej inwestycji a kontekstem tym jest model biznesowy i zakres projektu. Model biznesowy można wykonać nawet metodami formalnymi za pomocą pseudokodu czy języka relacji logicznych jednak model taki jest bezwartościowy, jeżeli nie stanowi sobą zrozumiałego przekazu dla każdego zaangażowanego w projekt czytaj „szczególnie klienta biznesowego”. Kluczem do sukcesu jest tu modelowanie czyli zobrazowanie w sposób zrozumiały dla każdej strony w projekcie IT istoty biznesu i jego kontekstu w projekcie tworzenia i wdrażania oprogramowania. Model biznesowy i wewnętrzna struktura zarządzania organizacji to nie obiektowe modele a procesowe mapy łańcuchów tworzenia wartości w firmie. Model obiektowy ma zastosowanie dopiero podczas tworzenia modeli informacyjnych czyli struktury danych przechowywanych i przetwarzanych w firmie a dane to nic innego jak reprezentacja tych informacji, które firma chce przetwarzać oraz sposób w jaki chce to robić o czym wielu analityków zdaje się zapominać. Jak więc prowadzić analizy wymagań?

Na początek można chyba polecić dość dobrze udokumentowane w literaturze metody analizy strukturalnej, której częścią jest modelowania procesów za pomocą Diagramów Przepływów Danych. Jako metoda analizy i pozyskiwania wymagań nieco sie skompromitowała (bardzo pracochłonna i trudna w obszarze korelacji modelu procesów i modelu danych) jednak uczy procesowego podejścia do analizy. Jako docelowe narzędzie polecam raczej współczesne modele procesów biznesowych zorientowane na produkty procesów (informacje). Tu polecam przestudiowanie dostępnej w sieci dokumentacji do takich notacji i narzędzi jak eEPC (program ARIS), BPMN (www.omg.org), ADONIS (własna notacja) i wiele innych w tym wiele zaawansowanych narzędzi CASE (Computer Aided System Engineering). Większość tych narzędzi ma wbudowaną możliwość użycia notacji BPMN i UML.

Dokumentacje te opisują głównie notację jednak na dostępnych tam przykładach można sie nie mało nauczyć. Naczelną zasadą modelowania jednak zawsze będzie zrozumiałość modeli dla członków modelowanych organizacji. Po drugie modelowanie to sztuka, nie da się tego nauczyć z jednej książki jak rzemiosła, nie ma gotowych procedur na wykonanie dobrego modelu. Modelowanie wymaga rozległej wiedzy i doświadczenia.

Na zakończenie: nie modeluj biznesu jeżeli go nie rozumiesz

Na koniec druga ważna uwaga: nie da się modelować organizacji i biznesu nie znając tych dziedzin. Modelowanie procesów biznesowych, jak sama nazwa wskazuje, wymaga wiedzy z zakresu i modelowania i procesów biznesowych czyli zarządzania i marketingu. Dlatego osoba pragnąca się nauczyć modelowania biznesowego może nie musi kończyć MBA ale powinna mieć dużą wiedzę z zakresu marketingu i zarządzania. Pamiętając także, że w definicji procesu biznesowego jest „tworzenie wartości” polecam przestudiowanie literatury takiej jak „trylogia” M.E.Portera, a przynajmniej jego „Przewagę konkurencyjną” gdzie dokładnie jest omówiona teoria łańcucha wartości i procesy biznesowe. Polecam także 3. rozdział (W jaki sposób informacja wpływa na przewagę konkurencyjną, w tym podrozdział Konkurowanie w epoce informacji) M.E.Porter „O konkurencji” gdzie opisano model łańcucha wartości w biznesie w postaci kluczowych procesów firmy rynkowej. Jak ktoś ma czas to może zaliczyć także „marketing” Kottlera to jednak jest bardziej operacyjny opis zarządzania. Polecam także gorąca ZarządzanieP.Druckera.

Podsumowując: systemy dla biznesu tworzone są na prośbę tego biznesu by w tym biznesie pomagać. Dlatego biznes na każdym kroku musi rozumieć opis tego co dostanie od analityka wymagań zaś na początek należy opisać (zamodelować) sam biznes i do tego potrzebne są między innymi modele biznesowe i modele procesów biznesowych.

Metodyki inżynierii oprogramowania, stosowane także w analizie wymagań na tak zwane „gotowe systemy”, zorientowane na model biznesowy i model dziedziny systemu należą do najskuteczniejszych i paradoksalnie najrzadziej stosowanych. Dlaczego? Moim zdaniem właśnie dlatego, że w wielu przypadkach pomija sie etap rzetelnej analizy biznesowej w projektach IT pozwalając, by opis wymagań wykonał od razu inżynier „bo to taniej”.

2010 r. Notatka: „Zdaniem analityków firmy decydujące się na wdrożenie systemu ERP mogą uniknąć rozjeżdzających się terminów i nadmiernie wysokich kosztów dzięki odpowiednio przeprowadzonej analizie przedwdrożeniowej. Eksperci podkreślają bowiem, że większość kosztów generowanych przez projekt wdrożeniowy nie ma nic wspólnego z kosztem samego oprogramowania. „Średnio trzy czwarte budżetu pochłaniają koszty wdrożenia, modyfikacji standardowej funkcjonalności oraz modernizacji sprzętu” – czytamy w raporcie Panorama Consulting Group.” (źr. IDG, 2010r)

P.S. 2016 r. 

Osobom zainteresowanym polecam opis jednej z metodyk analizy wymagań i projektowania zorientowanych na model biznesowy i model dziedziny systemu wraz z przykładowym projektem opisany w mojej książce Analiza Biznesowa.