W styczniu tego (2011) roku napisałem: Mamy więc analizę biznesową i specyfikowanie wymagań poprzez opracowanie weryfikowalnych modeli a nie tylko listę potrzeb, której niestety nie da się zweryfikować co do kompletności i spójności bo nie ma narzędzia sprawdzającego. Co jest takim narzędziem? Ano modele i to, że powstały (jeżeli powstały) przy pomocy sformalizowanej notacji. (źr. Analiza przedwdrożeniowa ? czym jest | Jarosław Żeliński – rynek IT, analiza biznesowa i projektowanie systemów).
Przyszła pora na opisanie samej analizy. Skoro więc analiza bazuje na modelach, najczęściej diagramach, pokusiłem się na, tym razem na nieformalny diagram obrazujący analizę systemową w kontekście inżynierii oprogramowania.
Mamy dwa elementy tej analizy: analizę systemową jako proces główny oraz modele jako narzędzia testowania hipotez. W przypadku projektowania celem jest projekt rozwiązania.
Standardowym narzędziem stosowanym przez większość analityków wymagań do przekazania wymagań na oprogramowanie jest ich specyfikacja. Problem w tym, że pierwszym testem tej specyfikacji jest tak na prawdę dopiero ich implementacja.
Alternatywnym podejściem jest analiza systemowa i modelowanie. Problem do rozwiązania to opracowanie oprogramowania, które zrealizuje cel zamawiającego. Zamiast jednak, np. z pomocą wywiadów, spisywać, nie poddające się żadnym testom, oczekiwania zamawiającego, tworzymy dwa modele:
- najpierw model firmy zamawiającego by na nim przetestować zrozumienie działanie samej firmy i ewentualnie ją nieco „zoptymalizować”,
- model przyszłego oprogramowania, które ma zaspokoić potrzeby zamawiającego czyli zrealizowawszy jego cel.
Celem jest oprogramowanie a dostawcy oprogramowania najmniej ryzykują gdy dostaną jego specyfikuję czyli gotowy projekt. Tak wiec przetestowany model oprogramowania realizujący cel zamawiającego jako wynik analizy systemowej stanowi nic innego jak opis produktu, który ma powstać. Oczywiście nikt nie projektuje od zera oprogramowania biznesowego bo to nierozsądne, wykorzystuje się tak zwane szkielety oprogramowania. O szkieletach już było tu: Frameworks Introduction ? czyli jak się psuje dobre ERP. A teraz zapraszam do obejrzenia tego co tu napisałem po mojemu czyli na diagramie 🙂 (tak zwane mapy myśli czasami sie przydają :)).
Warto tu zwrócić uwagę na jedną rzecz: ewentualne zmiany rozwiązania i korekty modelu (czyli projektu) odbywają się nadal na etapie analizy i projektowania, a wiec o rząd albo dwa taniej, niż podczas implementacji. Jest to główna przewaga tej metody nad analizą w postaci sesji JAD ([[JAD, ang. Joint Application Development]] – oznacza współtworzenie aplikacji, które czasami postrzegam jako świadome angażowanie klienta w proces projektowania by potem uczynić go współwinnym niepowodzenia) i opracowywania strukturalnych dokumentów.
Jeżeli zrezygnujemy z modeli pozostaje nam ryzykowna sesja warsztatowa (niejedna):
Przygotowując warsztat zbierania wymagań musisz być pewien, że zaprosisz na niego właściwe osoby. Pamiętaj wtedy, że:
- Twoi bezpośredni klienci (prezesi, dyrektorzy, właściciele firm) często nie znają tak naprawdę potrzeb i kontekstu pracy przyszłych użytkowników końcowych zamawianego systemu.
- Użytkownicy końcowi nie zawsze znają i rozumieją potrzebę biznesową dla tworzenia nowego oprogramowania.
- Klienci i użytkownicy końcowi nie znają technologii tak dobrze jak Ty i Twoja firma, więc nie będą w stanie zrozumieć szczegółów rozwiązań technicznych w tworzonym systemie.
- Ty i Twoja firma możecie nie rozumieć w pełni potrzeb klienta i problemu, który tworzone oprogramowanie ma rozwiązać.
Co z tym zrobić? Pamiętaj, aby zadbać, żeby przedstawiciele wszystkich powyższych grup brali udział w warsztatach, wówczas interes każdej ze stron będzie reprezentowany. (źr. serwis O wymaganiach)
Chyba czegoś nie rozumiem w Twoim podejściu. Przygotowujesz najpierw obecny model firmy, a później model końcowy po wdrożeniu oprogramowania, tak? Wytłumacz mi proszę w jaki sposób najpierw zbierasz informacje na temat stanu obecnego, a także na temat jaki problem oprogramowanie ma rozwiązać? Unikasz spotkań z klientem albo z użytkownikami końcowymi?
Cel warsztatu może być różny, ale jedną z jego cech jest to, że na koniec takiego spotkania powinniśmy coś uzgodnić (np. zakres projektu) lub coś wspólnie stworzyć (np. model przypadków użycia, diagram kontekstu, model biznesowy klienta).
Dla mnie większym ryzykiem jest brak konsultacji z klientem i użytkownikami końcowymi niż kilka spotkać z nimi w celu lepszego zrozumienia ich potrzeb. Uważasz, że lepiej jest samemu stworzyć wszystkie modele, a później implementację i dopiero na końcu przyjść do klienta i pokazać mu co zrobiłeś?
Być może uproszczenie nam „zaszkodziło”… :). Podchodzę do problemu wymagań tak jak lekarz (to także pewne uogólnienie): pytam ogólnie pacjenta jaki ma problem, potem robię obiektywne badania (krew, mocz, prześwietlenie itp.), czyli coś co jest niezależne od jego subiektywnego odczucia choroby. Ewentualne niejasności wyjaśniam dopiero w krótkiej rozmowie. Staram się zrozumieć jego organizm i jego stan a nie to co mówi pacjent. Problem w tym, że opowiadanie to wynik tego co widzi (rozumie) opowiadający i jego dotychczasowych (i tylko jego) doświadczeń (psychologia, teoria komunikacji społecznej).
Analizę prowadzę tak: pytam sponsora projektu co chce osiągnąć, proszę o plan marketingowy i strategię (jak ich nie ma robię je sam z ich pomocą), zbieram dokumenty jakich używa organizacja i na ich podstawie odtwarzam jej model informacyjny (taksonomia) i procesy. Taki model jest potem testowany z udziałem kadr kierowniczych.
Na gotowym modelu nanoszę zakres projektu, w obszarze zakresu uszczegóławiam procesy, dalej czynności w procesach objętych zakresem projektu są mapowane na przypadki użycia (są z nich wywodzone). Równolegle, na bazie dokumentów w procesach, powstaje model dziedziny dla MVC. Każdy nietrywialny przypadek użycia otrzymuje model sekwencji, Model Dziedziny uzupełniany jest o metody i atrybuty klas.
Po testach modeli, otrzymuję model będący koncepcją rozwiązania. Jest to „typowe” MDD (Model Driven Design). Metoda ma tę zaletę, że wymagania są dość odporne na subiektywizm pracowników zamawiającego, mało angażują jego ludzi a ryzyko nieodkrytych wymagań jest minimalne.
Tak wiec proces Analizy Systemowej ma w centralnej części modele i ich testowanie, te modele to kolejno model procesów biznesowych (BPMN) i model oprogramowania UML). Wymaganiem jest ten ostatni.
Dzięki za wyjaśnienie, teraz już lepiej rozumiem Twoje podejście, chociaż nadal mam swoje wątpliwości i wydaje mi się, że nie słusznie krytykujesz niektóre z opisywanych przeze mnie pomysłów. Tutaj akurat piszesz o warsztatach, ale to właśnie takie warsztaty możesz wykorzystać do weryfikacji swoich modeli.
Piszesz, że wolisz obserwować niż rozmawiać, bo to co klient mówi to jest jego subiektywna opinia. I właśnie po to mogą być wykorzystane warsztaty, na które oprócz klienta zapraszasz użytkowników końcowych, ekspertów z danej dziedziny, programistów, architekta, itp. – to pomaga lepiej zrozumieć problem zarówno analitykom jak i klientowi, pomaga odkryć nowe wymagania, inaczej spojrzeć na niektóre sprawy, pozwala odkryć konflikty w oczekiwaniach (szczególnie między sponsorem projektu a użytkownikami końcowymi).
Zastanawiam się też jak wygląda testowanie modeli. Każda kadra kierownicza jest w stanie w łatwy sposób zrozumieć diagramy UML?
Jeżeli odebrałeś to jak krytykę to przepraszam, moją intencją jest pokazanie czegoś innego dla przeciwwagi, innej – także (może mniej powszechnie) stosowanej – metody. Niewątpliwie są przypadki gdy każda ma swoje zastosowanie, ja raczej bronie tezy, mówiącej, że jeśli kupujący nie rozumie technologii, którą kupuje nie powinien brać udziału w jej tworzeniu, powinien być uczestnikiem opisywania oczekiwań, ale już nie tworzenia tego co zamówił (choć może to brzmieć dziwnie)… Są sytuacje, gdy JAD się sprawdza ale też, nie wyobrażam sobie by telewizor powstał na bazie sesji z przyszłymi oglądaczami meczy piłkarskich.
Jakiś czas temu wpadła mi w rękę książka Fowlera, w której wstępie napisał on ideę metody opartnej na modelach (MDD):
„Wyobraźmy sobie kogoś, kto chce napisać program, grę w snookera. Problem ten może zostać opisany przypadkami użycia opisującymi powierzchownie cechę: „Gracz uderza biała kulę, która przemieszcza się z pewną prędkością, ta po określonym czasie uderza czerwoną kulę pod określonym kątem, uderzona czerwona kula przemieszcza się na pewną odległość w pewnym kierunku.” Możesz sfilmować setki tysięcy takich uderzeń, zarejestrować parametry każdego uderzenia i jego skutki. Jednak tą metodą i tak nie stworzysz nawet dość dobrej symulacji. Aby napisać na prawdę dobrą grę, powinieneś raczej zrozumieć prawa rządzące ruchem kul, ich zależność od siły i kierunku uderzenia, kierunku itp. Zrozumienie tych praw pozwoli Ci znacznie łatwiej napisać dobre oprogramowanie.”
Rzecz w tym, że od gracza w snookera na pewno dowiesz tylko tego co chce on osiągnąć jako gracz, ale raczej nie poznasz praw fizyki, dzięki którym on w ogóle może tak grać jak chce…
Dlatego w systemach dla biznesu zakładam, że bardzo rzadko wszyscy pracownicy znają się na rynku, przewadze rynkowej czy rachunkowości, mimo tego, że maja duży udział w sukcesie swojej firmy…
Odpowiadając: jeśli pojawi się konflikt pomiędzy sponsorem projektu a użytkownikiem to jest to z definicji problem pozainformatczny… tu kompetencjami są negocjacje a nie inżynieria oprogramowania, w przeciwnym wypadku narażamy się pozycje między młotem a kowadłem…
Testowanie modeli: model procesów biznesowych w firmie (BPMN) testuję z jej pracownikami, ale modele UML projektu oprogramowania po protu testuje sam lub z programistami.
Jest to inna metoda, czy lepsza czy gorsza to kwestia projektu. Mam wrażenie, że projektach biznesowych, gdzie celem oprogramowania jest wspieranie zarządzania w firmie sprawdza się lepiej…
Teraz już znacznie lepiej rozumiem Twoje podejście. Wydawało mi się przez chwilę, że całkowicie krytykujesz podejście ściślejszej współpracy z klientem. Zgadzam się z Tobą, że są różne projekty, w niektórych zapewne Twoje podejście sprawdza się bardzo dobrze, jednak wydaje mi się, że są sytuacje, kiedy bliższa współpraca z klientem może dać lepsze efekty.
Dziękuję za wyjaśnienie.
Sytuacji, w których sprawdza się podejście stałego kontaktu z klientem jest dużo, moim zdaniem zawsze tam gdzie celem projektu jest właśnie subiektywizm zamawiającego, który nie musi być racjonalny a mimo to jest skuteczny, w szczególności chyba projekty związane ze stronami WWW, programami lojalnościowymi, akcjami promocyjnymi itp. Bał bym się jednak ta metodą wdrażać systemy raportowe, zarządzanie przepływem pracy czy zaawansowane systemy CRM (czym by nie były…;)), po protu system, którego złożoność przekracza możliwości prostej wyobraźni typowego człowieka wymaga (podobnie jak kule snookera) innego podejścia niż ankiety.
P.S. Dlaczego przy moich komentarzach pojawia się taka rozzłoszczona mordka? 😉
te mordki są generowane losowo każdemu komentującemu, nie mam wpływu na wynik losowania :D.
czy to jest cała część analizy systemowej ?
To jest to, co nazywa się Analiza Systemowa, której źródło tkwi w Ogólnej Teorii Systemów (nie należy tego utożsamiać z Systemami Informatycznymi).