Historia pewnego mojego klienta

Zalecenie dla zamawiających: zawsze patrze na ręce wykonawcy… prośba do programistów: Jak piszecie kod, którego celem jest szyfrowanie transmisji, renderowanie obrazków itp. to róbcie to jak najlepiej potraficie ale jak implementujecie model dziedziny to dajcie mu spokój, to nie Wasz problem, po protu skopiujcie go, a jak Wasz analityk nie potrafi Wam dać takiego modelu obiektowego to zmieńcie analityka…Po drugie wykonawca, który składając ofertę zaakceptował projekt (wymagania) a potem neguje treść tego projektu … kim jest?

Czytaj dalej Historia pewnego mojego klienta

Hej, Biznesie, to ma być dla biznesu czyli dla Ciebie!

Tak więc jest metoda, praktyka pokazuje, że sprawdza się. Praktyka pokazuje także, że niestety nie jest to łatwe (modelowanie biznesu metodami obiektowymi, tu niestety nie da się powiedzieć, że “nie święci garnki lepią”) dlatego powstały pewne zalecenia i wzorce projektowe. Należy je zrozumieć, nauczyć się stosować i stosować, co i tak nie zastąpi “projektowania” czyli twórczego pierwiastka w tym procesie. Dokładnie tak samo jak nie da się automatycznie tworzyć kodu programu, do tego potrzebni są (dobrzy) programiści.

Z przekorą powiem też, że nie wiem jak zwinność metod programistycznych ([[Agile Manifesto]]) miała by ten proces uzdrowić i uczynić lepszym (nadal uważam, że brak dokumentacji, w tym modeli, raczej psuje projekty). Podsumowując można by powiedzieć, że etapy tworzenia oprogramowania to:

Analiza biznesowa, której produktem są: model organizacji (CIM) oraz specyfikacja tego co ma powstać (PIM), to drugie to kompletne wymagania. Całość (sformalizowane modele) pozwala na przetestowanie czy tak określone wymagania spełniają potrzeby biznesu.
Wytworzenie oprogramowania polegające na: implementacji modelu PIM, rozwiązaniu problemów technicznych (wymagania niefunkcjonalne) oraz dostarczeniu i wdrożeniu.
Powyższe, tak udokumentowany projekt, pozwala także osiągnąć dodatkową korzyść: “wiedza organizacji” tkwi w modelu PIM i developer nie może jej przejąć bez zgody autora, Analityka Biznesowego i sponsora projektu (prawo autorskie).

Czytaj dalej Hej, Biznesie, to ma być dla biznesu czyli dla Ciebie!

Agilian nowa wersja. Burza mózgów sformalizowana …

Po co nam CASE?

Bo

Dzięki narzędziom CASE projekty tworzy się dokładniej, a praca nad diagramami, sprawdzanie ich poprawności oraz śledzenie wykonanych testów jest prostsze i szybsze. (wiecej: http://www.eioba.pl)

Tak więc gorąco polecam stosowanie narzędzi (lista narzędzi CASE).

Z zasady nie reklamuje oprogramowania. Uważam, że jego sprzedawanie to inna kompetencja. Jednak nie da się ukryć jestem użytkownikiem “czegoś”. Czym to jest? Pakiet typu [[CASE]] [[Visual-Paradigm Agilian]]. I co my tu mamy? Wczoraj dotarł do mnie upgrade i… mamy burzę mózgów :):

Czytaj dalej Agilian nowa wersja. Burza mózgów sformalizowana …

BPM 2.0 czyli nowe mity…

Powyższego niestety nie zrozumiałem (co to znaczy “możliwości wykorzystania różnych metod do relatywnie łatwej integracji z innymi wykorzystywanymi systemami”), nie licząc tego, że faktycznie dobrze wdrożone systemy wspomagające zarządzanie przepływem pracy i dokumentów, jest swego rodzaju systemem pracy grupowej. Integracja, jej łatwość i koszt zaś nie zależy od systemu BPM a tych integrowanych systemów ERP czy CRM.

Tak więc nie sądzę by możliwe było projektowanie i wdrożenie systemu bez “służ informatycznych”. Jednak dobrze zaprojektowany i już wdrożony system BPM może pozwalać na komponowanie kolejnych nowych lub zmianę starych procesów, jednak tu możliwe jest jedynie używanie wstępnie zaprojektowanych i zaimplementowanych “procesów i obiektów danych” jak z klocków.

Czytaj dalej BPM 2.0 czyli nowe mity…

Metoda naukowa w analizie biznesowej

Po kolei:

obserwacje to analiza tego co i jak się w firmie dzieje (analiza dokumentów i wywiady)
budowanie hipotezy to tworzenie modelu procesowego tej firmy i modelu jej dziedziny
eksperymenty to testowanie modeli poprzez sprawdzanie czy model procesu da jako produkt taki sam dokument jak te w praktyce
przyjęcie lub odrzucenie hipotezy oraz jej powtarzanie to iteracyjne testowanie i ulepszanie modelu (jeśli był wadliwy)

Czytaj dalej Metoda naukowa w analizie biznesowej

Miejsce BPMN w odniesieniu do UML

To, że UML jest obcy większości analityków biznesowych to przykra prawda, dzisiaj raczej źle świadcząca o tej większości (patrz model kompetencji analityka biznesowego IIBA). Używanie UML do modelowania procesów biznesowych jest ograniczaniem możliwości tych modeli gdyż UML reprezentuje paradygmat obiektowy a BPMN procesowy a to dwa odrębne światy (to, że powstały i są wykorzystywane równolegle te dwie, różniące się od siebie, notacje notacje także o tym świadczy). Trudno także mówić o “podejściu” do modelowania procesów w UML bo to tak, jak by mówić że “łodzie reprezentują zupełnie odmienne podejście do poruszania się po drogach publicznych”. Niestety są żeglarze, którzy nie uznają innej prawdy niż ta, że łodzią można wszędzie, trzeba się tylko postarać. Faktem jest, trzeba się dobrze postarać. […] Co do wymagań samych narzędzi UML nie podejmuję się dyskusji bo narzędzia są rożne i każdy sam sobie je dobiera. Co do samej ścieżki analizy to raczej w pierwszej kolejności modelujemy biznes (modele BPMN) a potem dopiero zastanawiamy się i projektujemy narzędzie, oprogramowanie dla tego biznesu czyli pora na UML. Odwrotną kolejność sugerują dostawcy gotowego oprogramowania ale ten wątek był na tym blogu już nie raz poruszany.

Czytaj dalej Miejsce BPMN w odniesieniu do UML

Analiza a programowanie czyli gramy w chińczyka na szachownicy

proszę programistów: róbcie to co rozumiecie i nie wmawiajcie nikomu, że wiecie lepiej jak zarządzać firmą Waszych klientów. Róbcie to co każdy dobry stolarz: poproście klienta o rysunek tego co ma powstać i zróbcie. Nie zapominajcie, że dobry stolarz to nie to samo do dobry projektant, jak klient nie potrafi rysować (a najczęściej nie, bo nie to jest jego kompetencją), dobry stolarz zawsze odeśle do projektanta po rysunek. Między innymi dlatego, by później nie być posądzonym o stronniczość czyli rysowanie tylko tego co jest łatwe w wykonaniu. Rzecz w tym, że nie ma być łatwe dla stolarza a dobre dla klienta.

Czytaj dalej Analiza a programowanie czyli gramy w chińczyka na szachownicy

Ach ten wstrętny, wścibski analityk

Cóż, zastąpienie procesu analizy i projektowania werbalną komunikacją to droga na skróty: czerwona strzałka. Czy to zła droga? Droga na skróty to wspomniane na początku ryzyko, ogromne bo statystyki wskazują stale, że ok. 70-80% projektów programistycznych ma poważne kłopoty. Statystyki te są takie same od lat.

Od lat znany jest powyższy proces i mimo to zawsze jest te 80% klientów i ich dostawców, którzy dogadują się, że analiza i projektowania żadnemu z nich nie służy… tak jak to napisano na początku.

Po co to napisałem? By każdy z Państwa sam, świadomie, oceniał ryzyko swoich projektów. Rezygnacja z analizy i projektowania to podjęcie pewnego ryzyka, przez klienta. Niestety rezygnacja z analizy i projektowania ze strony dewelopera to czasem dodatkowo skutek uznania, że analiza i projektowanie leży poza kompetencjami programistów (Ci obiektowo kodują) wiec wybierają jest droga na skróty.

Czytaj dalej Ach ten wstrętny, wścibski analityk