Jarosław Żeliński analityk biznesowy Prezentacja prowadzonej działalności, sposobu prowadzenia procesu analizy i projektowania oraz zasad współpracy

Transkrypt

1 Jarosław Żeliński analityk biznesowy Prezentacja prowadzonej działalności, sposobu prowadzenia procesu analizy i projektowania oraz zasad współpracy

2 Od 1991 roku w branży IT i zarządzania Od 1998 roku jako niezależny analityk, projektant i firma IT-Consulting.pl Dziesiątki publikacji w prasie branżowej i gospodarczej Członek Stowarzyszenia Doradców Gospodarczych Wykładowca Katedry Systemów Informacyjnych Wydziału Przedsiębiorczości Akademii Morskiej w Gdyni Kilkudziesięciu odbiorców usług doradczych, małe, średnie i duże firmy zarówno informatyczne jak i ich klienci oraz administracja publiczna. Poświadczenie bezpieczeństwa wydane przez ABW Publikacje między innymi w 2

3 RYNEK klienci IT-Consulting Jarosław Żeliński Działalność na rynku niezależnych usług eksperckich Zarządzanie firmą, świadczenie usług eksperckich, opracowywanie i prowadzenie szkoleń Strona WWW z ofertą Realizacja bieżących projektów Działalność publicystyczna, badawcza, dydaktyczna Stałe studia literatury i prace badawcze, udział w konferencjach i seminariach Eseje o rynku IT e-learning Autorskie publikacje, referaty na konferencjach Szkolenia i konsultacje 3

4 Aby zminimalizować ryzyko projektu Zamawiający powinien w specyfikacji wymagań dokładnie określić czego potrzebuje, dostawca na tej podstawie dopiero określi co musi dostarczyć i jakim kosztem jest w stanie tego dokonać. Ale jak opisać to czego naprawdę potrzebujemy? Inżynieria oprogramowania to tworzenie i dostarczanie oprogramowania spełniającego oczekiwania, w tym także wdrożenie gotowego oprogramowania jeśli spełnia te oczekiwania. Pierwszym podstawowym problemem do rozwiązania nie jest jednak spisanie tych oczekiwań w postaci specyfikacji wymagań, bo to jest drugi krok, a odkrycie jak naprawdę pracujemy oraz w czym i jak oprogramowanie ma nam pomagać bo z tego będzie wynikało to czego oczekujemy. 4

5 Idealny proces wytwórczy: 1. klient (zamawiający) dobrze opisał swoje oczekiwania i podał wszystkie istotne informacje 2. developer dobrze wszystko zrozumiał i określił budżet, termin i zakres projektu 3. developer od razu napisał dobry kod - dobre oprogramowanie Ale jak wiemy: 1. jeżeli jest ryzyko, że klient w sposób niekompletny opisze swoje oczekiwania należy wykonać analizę biznesową i ją udokumentować (powstaje model firmy klienta, który on zatwierdza) 2. jeżeli jest ryzyko, że developer nie zrozumie biznesu należy przetworzyć model biznesowy i cele biznesowe klienta na wymagania na oprogramowanie w postaci przypadków użycia i modelu dziedziny 3. jeżeli jest ryzyko, że developer nie napisze od razu dobrego oprogramowania należy stworzyć koncepcję architektury, opisać sekwencje realizacji przypadków użycia przez obiekty modelu dziedziny i komponenty, jak obiekty modelu dziedziny zrealizują interfejsy komponentów. Koncepcyjny model nowego oprogramowania to jedyny i najlepszy zarazem sposób zweryfikowania czy ono zadziała jeszcze przez rozpoczęciem implementacji. Ten etap stanowi także weryfikacje kompletności projektu. To autor analizy biznesowej wie najlepiej jak pracuje organizacja i to on posiada wiedzę by te działania odwzorować za pomocą oprogramowania dlatego dobrze jest, szczególnie w przypadku systemów dedykowanych, gdy analityk przekaże wymagania w postaci koncepcji nowego systemu a nie tylko jego opisu, bo to materiał, który rozumieją programiści wykonawcy. 5

6 6

7 Kosztowna pętla odkrywania wymagań Analiza wymagań Projektowanie Wykonanie Wdrożenie 3% 27% 55% 15% Specyfikacja wymagań Analiza Realizacja Użytkowanie 10-20% 13% 20-40% 5% Nowa wersja systemu (ewolucja) 30-50% oszczędzonego czasu i środków budżetowych, w tym czasie developer realizuje kolejny projekt zarabia. źr. IBM Praktyka pokazuje, że czas i środki poświęcone na analizę i projektowanie skracają proces implementacji. Głównym źródłem oszczędności jest wypracowany na początku i przetestowany model systemu dzięki czemu praktycznie unikamy pętli odkrywania nowych wymagań, nowych faktów już na etapie implementacji. Nie występują więc najbardziej kosztowne poprawki systemu w tym poprawki modelu danych. W dobrze prowadzonym projekcie analiza jest powtarzana tylko w celu wytworzenia nowej wersji systemu. Korzyści odnoszą tu i klient i wykonawca: System jest tańszy i dostarczony w krótszym czasie - korzysta klient Dotrzymane zakładane termin i pracochłonność to zachowanie pierwotnej planowanej marży korzysta wykonawca, w kontraktach fixed-price każde opóźnienie to utrata zysku Ryzyko porażki projektu sprowadzone do minimum korzystają wszyscy

8 Analizy i specyfikacje zorientowane na modele

9 My Inne podmioty systemu Przedmiot wspólnego zainteresowania Relacje i zależności w systemie 9

10 Elementy naszego wnętrza Procesy i reguły biznesowe 10

11 To chcemy otrzymać Produkt, który jest nam potrzebny: nasze oprogramowanie To są nasze prawdziwe wymagania Informacje o tym co przetwarzamy Informacje o tym jak to robimy 11

12 Opracowanie modelu biznesowego i kontekst projektu Cel biznesowy Opracowanie mapy kluczowych procesów biznesowych Model funkcjonowania firmy Opracowanie wewnętrznych scenariuszy procesów biznesowych i modelu danych Opisy przepływu pracy, model informacyjny Opracowanie specyfikacji wymagań, listy reguł biznesowych Wymagania na oprogramowanie i ograniczenia, Opracowanie scenariuszy przypadków użycia i GUI dla projektów dedykowanych Model przypadków użycia 12

13 1. Analiza biznesowa 1.1. opis celu projektu, lista ograniczeń 1.2. opis działalności zamawiającego 1.3. model kontekstowy - model biznesowy zamawiającego 1.4. model procesów biznesowych na poziomie "value chain" 1.5. modele procesów biznesowych objętych zakresem projektu 2. Specyfikacja wymagań 2.1. specyfikacje funkcjonalności (opcjonalnie przypadków użycia wraz z ekranami i scenariuszami) i interfejsów 2.2. model dziedziny wraz z opisem atrybutów i metod (model danych i reguł biznesowych) 2.3. ograniczenia (wymagania niefunkcjonalne) 2.4. raporty (specyfikacja raportów i ich treści) 2.5. dane o liczbie generowanych operacji w systemie w jednostkach czasu oraz liczba użytkowników i ról w systemie (jeśli nie podano w ograniczeniach) 2.7. koncepcja architektury, integracja z otoczeniem 13

14 Zbieranie danych Analiza i modelowanie Specyfikowanie Wzory dokumentów Mapy procesów biznesowych Lista przypadków użycia Struktura organizacyjna Model architektury systemu Lista ograniczeń Lista interfejsów Wzory raportów Model dziedziny Model danych Opracowanie własne, Jarosław Żeliński 14

15 Analiza dokumentacji Analiza celu biznesowego Modele (hipoteza) Cel projektu Wywiad (testowanie hipotezy) Raport Korekta modeli Specyfikacja wymagań tak Modele (hipoteza) Analiza zakresu projektu Modele nie Kolejny wywiad? Opracowanie własne, Jarosław Żeliński 15

16 Specyfikacja wymagań na oprogramowanie Model procesów Modelowanie i optymalizacja Specyfikacja procesów i kluczowych mierników jakości Specyfikacja kosztów działań Opracowany w toku analizy model procesów biznesowych może posłużyć jako uniwersalne narzędzie do innych analiz i projektów Struktura organizacyjna zasobów ludzkich 16

17 Poza funkcjonalne cechy systemu Przedmiot analizy biznesowej wymagań: istota modelowanej firmy Dziedzina systemu Gotowy system lub szkielet oprogramowania Pisanie od zera tej części systemu nie jest potrzebne. Ekrany są budowane na podstawie Modelu, sterowanie (Controller) jest gotowe. 18

18 Czas trwania Opracowanie własne, Jarosław Żeliński 19

19 Wymaga wysokich kwalifikacji po stronie analityka ale nie wymaga żadnego doświadczenia analitycznego po stronie zamawiającego (zamawiający jest jedynie odpytywany). Wymaga ścisłej współpracy i pełnej dyspozycyjności zamawiającego jednak zajmuje bardzo mało czasu zamawiającemu (zamawiający musi być dyspozycyjny ale nie musi sam niczego wypracowywać nie traci czasu nie licząc bardzo krótkich wywiadów i kolekcjonowania własnych dokumentów ) Dokumenty wymagają wiedzy od wykonawcy oprogramowania (notacja i metodyka obiektowa) jednak zamawiający zatwierdza wyłącznie zrozumiały dla niego opis własnej organizacji i specyfikację przypadków użycia. Projekty analityczne tego rodzaju trwają od kilku dni do kilku miesięcy, pracochłonność analizy wymagań, zawierającej analizę biznesową poprzedzającą specyfikowanie tych wymagań, zależy od bardzo wielu czynników, kluczowe to: Skala projektu (jaki obszar organizacji obejmuje) Ryzyko jakie projekt niesie dla organizacji (jaki cel biznesowy realizujemy i jakie są potencjalne skutki niepowodzenia) Stopień innowacyjności projektu (ile problemów zostało już rozwiązanych i rozwiązania te są dostępne na rynku a ile należy rozwiązać w trakcie projektu) Analiza może trwać dowolnie krótko lub długo, metoda od ogółu do szczegółu gwarantuje nam, że można przerwać pracę w dowolnym momencie i zawsze otrzymamy kompletny raport, co najwyżej jego wyniki będą mniej lub bardziej ryzykowne. Oznacza to, że zamawiający zawsze może świadomie określić budżet na analizę. Kluczową zaletą opisanej tu metody prowadzenia projektu z zakresu inżynierii oprogramowania jest bardzo małe ryzyko popełnienia błędu w specyfikowaniu wymagań a te błędy są w 100% przypadków podawane jako przyczyna porażek tego typu projektów. 22

20 Szanowny Panie, [ ] Jestem specjalistą w zakresie HR i poszukuję wspólnego języka z programistami tworzącymi czasami dla mnie oprogramowanie. Potwierdzam Pana zdanie - metody opisowe i zorientowane na przypadki użycia metody nie są skuteczne a nawet powiem bezużyteczne gdyż programiści nie czytają ich do końca. Proszę o pomoc i z góry dziękuję. 23

21 Jestem pod wielkim wrażeniem Pana artykułów, tym bardziej, że na przykładzie własnej firmy miałem okazję doświadczyć problemów wdrożeniowych, których przyczyny i skutki Pan opisuje. Niestety mimo najwyższej staranności i zaangażowania z naszej strony jeden z GoldPartnerów i jednocześnie laureat nagrody partnera roku firmy Microsoft zdołał "modelowo położyć na łopatki" nasz projekt. W związku z tym pewnie będę miał przyjemność popracować z Panem. Jak się domyślam, prawdopodobnie w ten właśnie sposób trafia do Pana większość klientów. 24

22 No naprawdę świetny dokument. Zajrzałem do tego pdf-a [przykładowa analiza*] i muszę powiedzieć że treść i forma super, gratuluję. Gdyby każdy projekt w IT był robiony na podstawie takiej specyfikacji to może inaczej wyglądałyby proporcje projektów zakończonych do porzuconych. *Opinia o dokumencie wymagań wykonanego opisaną metodą. 25

23 Co do Pańskiej analizy dla Vectry. Ja otrzymałem jedynie diagramy UML procesu windykacji. Stanowiły one punkt wyjścia do wdrożenia systemu Siebel jako systemu informatycznego wspomagającego ten proces. Przygotowane diagramy pozwoliły w jednoznaczny sposób nakreślić warunki brzegowe przygotowanej oferty. W czasie późniejszych prac stanowiły punkt odniesienia poszczególnych podprocesów w procesie windykacji. Przygotowana przez Pana analiza w bardzo dokładny sposób odzwierciedlała rzeczywistość biznesową działu windykacji Vectry. Wola Info SA, Kierownik Projektu Siebel CRM dla Vectra SA 26

24 "Współpraca z Jarkiem Żelińskim pokazała nam, że nasi programiści nie powinni jeździć do klienta bo tego nie lubią. Jarek opracował bardzo dobrą dokumentacje systemu, namówił klienta do rezygnacji z kosztownych a mało przydatnych funkcji, które niepotrzebnie podnosiły pracochłonność a projekt przewidywał wprowadzanie zmian w przyszłości minimalnym kosztem, zrezygnowaliśmy z zatrudniania etatowego analityka gdyż wolimy mieć bardzo dobrego analityka i zawierać z nim umowy tylko do realizacji projektów." 27

25 gwarancja Jako analityk zawieram umowy na analizę zarówno z kupującymi oprogramowanie jak i z jego dostawcami. W moim modelu biznesowym koszty poniższych trzech kompetencji (analiza, zarządzanie projektem, wdrożenie) występują zawsze, mogą być różnie rozłożone pomiędzy strony dostawca-wykonawca oprogramowania. Koszt analizy (IT-CONSULTING) Nadzór autorski Koszt zarządzania projektem Koszt dostarczenia i wdrożenia oprogramowania (dostawca oprogramowania) 28

26 PERSPEKTYWA OBSERWATORA Z ZIEMI (SYSTEM GEOCENTRYCZNY) ODKRYTA PRAWDA (SYSTEM HELIOCENTRYCZNY) Prawdę odkrył i udokumentował Kopernik, człowiek który nie szukał poklasku ani u zwykłych ludzi patrzących z wiarą w niebo, ani u tych, w których interesie było, by Ci ludzie wierzyli, że Ziemia to centrum ich świata. Ta prawda w efekcie wszystkim dobrze służy mimo początkowego oporu. Praktyka pokazuje, że systemy obserwowane z ich wnętrza wydają się bardzo skomplikowane i tak też są opisywane przez zwykłych ludzi. W rzeczywistości większość systemów jest znacznie prostsza jednak odkrycie tego wymaga spojrzenia z zewnątrz i uznania, że jesteśmy częścią czegoś większego a nie jego centralnym punktem. Dlatego warto zawsze wykonać pełną analizę a nie tylko zapisać to co widzą obserwatorzy. Rzemieślnicy produkujący przed Kopernikiem skomplikowane i kosztowne przyrządy do określania położenia planet i gwiazd z wiadomych powodów nie byli zainteresowani upraszczaniem tego modelu i swoich skomplikowanych przyrządów 29

27 Problemy, w których rozwiązaniu mają pomóc budowane złożone systemy są zwykle problemami złośliwymi (Rittel i Webber, 1973). Problem złośliwy to taki skomplikowany problem, w którym jest tak wiele powiązanych ze sobą bytów, że nie istnieje jego ostateczna specyfikacja. Prawdziwy charakter problemu objawia się dopiero w miarę opracowywania rozwiązania.

28 Jeśli tak, to zapraszam na dalszą prezentację lub spotkanie 32