CASE czyli komputerowe wspomagania analizy i projektowania systemów

I teraz sedno czyli co nam daje dobre narzędzie CASE? otóż powyższe macierze (takie i każdą inną) oraz model analizy wpływu, są generowane i aktualizowane automatycznie. Wystarczy opracować standardowe modele w BPMN i UML jak powyżej, wskazać związki pomiędzy elementami jako ich parametry (nie trzeba do tego celu tworzyć sztucznych diagramów) i skorzystać z możliwości automatyczne dokumentowania tych związków.

Czytaj dalej CASE czyli komputerowe wspomagania analizy i projektowania systemów

Dokumentowanie wymagań na oprogramowanie

Produkt: Opis Przedmiotu Zamówienia (opracowanie specyfikacji SWS) zawierający zarówno udokumentowany Model Biznesowy Organizacji jak i Projekt Techniczny Rozwiązania, realizowany jest także nadzór autorski nad realizacją. Korzyści: ochrona know-how Zamawiającego, kompletne…

Czytaj dalej Dokumentowanie wymagań na oprogramowanie

Stosowane metody analizy biznesowej i projektowania

Jeżeli czegoś nie potrafisz narysować, to znaczy, że nadal tego nie rozumiesz, jeżeli coś jest trudne do narysowania, to tym bardziej będzie to trudne do realizacji.(JarosŁaw Żeliński) Wprowadzenie Podstawowe pojęcie…

Czytaj dalej Stosowane metody analizy biznesowej i projektowania

Nieudane wdrożenie systemu biznesowego – czy uczymy się na błędach innych

Jeżeli jednak okaże (analiza) się, że zakup programu ma pomóc, to należy opisać wymagania jakie taki program musi spełnić (wymagania wobec produktu). Te wymagania są podstawą do wyboru gotowego, dostępnego na rynku oprogramowania, lub decyzji o napisaniu dedykowanego, jeżeli poszukiwania nie dadzą pozytywnego rezultatu (ale etap szukania gotowego powinien dla zasady mieć miejsce). Dedykowane rozwiązanie wymaga jego zaprojektowania, to można (zalecane) zrobić przed wyborem wykonawcy lub zlecić wybranemu wcześniej wykonawcy. Wariant drugi naraża nas jednak na utratę panowania nad projektem bo wykonawca będzie forsował metody budujące mu marże a potem sam sobie świadczy nadzór autorski. Wbrew pozorom, angażowanie audytora projektu, który nie jest autorem dokumentacji wymagań nie wnosi nic, a komplikuje cały proces: taki audytor może jedynie ocenić zgodność działań projektowych z dokumentacją wytworzoną przez (audytowanego) wykonawcę, a w przypadku sporu i tak tu “władzę” ma autor projektu a nie audytor.

I teraz: ogłoszenie przetargu na całość na początku tej drogi jest jak widać idiotyzmem bo nie mamy żadnej wiedzy by ocenić wynik pracy a dostawca żadnej by cokolwiek sensownie wyceniać. Pominięcie jakiegokolwiek z tych w/w opisanych etapów to podnoszenie ryzyka projektu, co mam na dzieję widać. Każde wymaganie może być zero jedynkowe na każdym z tych etapów, wystarczy chcieć i umieć. Owszem, można je dzielić na biznesowe itp… ale to tylko sztuczne podziały, po prostu podczas realizacji mamy już tylko etap i jego wymagania. (Nieudane wdrożenie systemu biznesowego – czyli uczmy się na błędach innych | LinkedIn).

I tylko tu pojawia się pytanie jak w filmie MIŚ: a może to faktycznie ma być drogie i nieprzydatne a ja zupełnie bez sensu jestem tym zdziwiony?

Czytaj dalej Nieudane wdrożenie systemu biznesowego – czy uczymy się na błędach innych

Modelowanie struktury organizacyjnej – widać światełko w tunelu

Na konferencjach i forach toczą się stale dyskusje na ten temat. Większość firm doradczych, informatycznych i ich analitycy bronią tezy, że celem analizy jest zebranie informacji w postaci dokumentów i zestawień. Niestety takie dokumenty są kompletnie nieprzydatne, mają wartość nagrania (patrz wyżej zdjęcie lotnicze), nie da się na ich postawie wyciągać żadnych pozwalających na dowodzenie ich słuszności, wniosków nie licząc może oceny estetyki edytorskiej. Niewątpliwą “zaletą takiej analizy” jest to, że nie wymaga ona absolutnie żadnych kompetencji poza umiejętnością komunikacji. Takim analitykiem może być niemalże każdy (łatwa rekrutacja, niski koszt), ale czy taki jest cel analiz poprzedzających projekty, warte setki tysięcy złotych a nie raz miliony?

Na zakończenie dodam, że najgorszym sposobem jaki znam i jaki niestety często spotykam, na modelowanie struktury organizacyjnej, jest użycie diagramu klas lub diagramu przypadków użycia i modelowanie z zastosowaniem dziedziczenia (klas lub aktorów).

Czytaj dalej Modelowanie struktury organizacyjnej – widać światełko w tunelu

Inżynieria wymagań

Wymagania interesariuszy. Moja definicja interesariusza (jedna z wielu): osoba (podmiot) zainteresowana zaistnieniem produktu, na którą pojawienie się produktu ma wpływ. Nie raz jestem pytany czy interesariusz ma prawo zgłaszania wymagań. Jeżeli ma coś do powiedzenia podczas odbioru produktu to znaczy, że ma wymagania. One mogą być jednak niejawne czyli taki interesariusz nie zgłasza wymagań ale ma wpływ na odbiór produktu, należy go koniecznie zidentyfikować. Jeżeli zaś ktoś nie ma nic do gadania przy odbiorze produktu nie jest interesariuszem (ang. stakeholder, kluczem jest tu ‘holder’ czyli dysponent mający coś do powiedzenia, mający wpływ). Tak wiec interesariusz to ktoś kto, na swoim poziomie ogólności, także musi umieć określić, kiedy uzna, że produkt spełnia jego wymagania. Jak nie potrafi, ktoś musi mu pomóc…analityk :)).

I tu rola analityka. Interesariusz spisuje co mu przyjdzie do głowy swoim językiem, analityk upewnia się, że zrozumiał, doprowadza je do postaci testowalnej i klasyfikuje “wymagania” jako “źródło: konkretny interesariusz” (bo każde wymaganie musi mieć właściciela). Proszę zwrócić uwagę, że interesariuszem jest także użytkownik jeżeli tylko ma coś go powiedzenia w projekcie :).

Czytaj dalej Inżynieria wymagań

Semantic Core czyli bat na szczegóły

Bardzo często zastanawiam się, nad przyczynami porażek projektów, przyczynami tego, że jedne są lepsze inne gorsze, a gorszy to taki, który wymyka się spod kontroli a ostateczny efekt (produkt), uzyskany po znacznie dłuższym czasie niż planowano, jest zaskoczeniem dla wszystkich. Na to nakłada się problem przekazywania wiedzy pomiędzy kolejnymi etapami projektu, gdzie największym ryzykiem jest zrozumienie problemu i przekazywanie wiedzy przez samego zamawiającego. Gdzie problem?

Ten artykuł polecam “biznesowi” który szuka przyczyn swoich problemów, i tym (nie tylko analitykom), którzy mają ambicje robić coś w kierunku poprawy tego stanu rzeczy, zamiast uznawać obecne statystyki za pewnik bo “takie są fakty”. […] Ktoś może powiedzieć: biznes tego (notacje, modele itp.) nie rozumie. I ma racje, bo to narzędzia a nie produkty analiz. Produktem analizy dla biznesu są zawsze rekomendacje (wymagania na oprogramowanie to także rodzaj rekomendacji brzmiącej: zalecam by takie warunki spełniało to oprogramowanie). Zamawianie przez biznes modeli jako takich, to jakieś koszmarne nieporozumienie. To tak jak by np. prawnik, jako produkt zlecenia “opinia prawna” oddał wybrany stos kodeksów z komentarzami. Nie, dobry prawnik oddaje jedna stronę rekomendacji: opinie prawną. To, że skorzystał z tych kodeksów to jego narzędzie pracy, możliwe, że załączy je do tej tej opinii (ale raczej jako materiał dla innego prawnika lub audytora).

Czytaj dalej Semantic Core czyli bat na szczegóły

Relacja z konferencji Cloud Solutions 23.01.2013, Warszawa

  23 stycznia w Warszawie odbyła się premierowa edycja konferencji Cloud Solutions, zorganizowana przez Platinium Cast, pod honorowym patronatem Ministra Administracji i Cyfryzacji Michała Boniego. Podczas konferencji poruszono tematy związane…

Czytaj dalej Relacja z konferencji Cloud Solutions 23.01.2013, Warszawa