Zapraszam wszystkich, którzy szukają pomocy, wiedzy oraz wsparcia w swoich projektach informatyzacji. Działam od 1991 roku, mój Blog działa nieprzerwanie od 1998 roku.
Inżynier systemów biznesowych i projektant oprogramowania. Jestem pomostem między biznesem a deweloperem.
Regularnie obserwuję pewną trudność jaką sprawia wielu ludziom, z jednej strony stosowanie systemów notacyjnych a z drugiej samo modelowanie. Wspólną częścią obu tych obszarów jest abstrahowanie od szczegółów. Praktycznie każdy mój klient i bardzo często, analitycy i projektanci developerów realizujących projekty które nadzoruję, zadają mi pytania: a gdzie zobaczę to, że zamówienie może być dla innego produktu i innego segmentu..... itp. Innymi słowy: na dowolnym etapie pracy padają pytania o bardzo detaliczne szczegóły konkretnych operacji. Co prawda, jak to mawiają "diabeł tkwi w szczegółach", z czym wypada się zgodzić, ale…
Dzisiaj będzie bardzo krótki wpis, którym niemalże w całości będzie cytat z artykułu pewnego programisty. Każdy analityk i projektant powinien przeczytać cały artykuł (nie jest długi) i koniecznie komentarze pod nim. Jeden komentarz zacytuje bo jest znamienny, choćby dlatego, że moje doświadczenia są dokładnie takie same: Co Ty człowieku, życia nie znasz? Przecież w realu jakbyś poszedł do takiego i podzielił się takimi uwagami to foch na pare tygodni co najmniej gwarantowany. Kiedyś miałem podobną sytuację (a raczej serię sytuacji, ale dotyczących rzeczy o mniejszej skali) to efekt był taki,…
Warto tę książkę przeczytać, by poznać dobrze opisaną, spójną koncepcję analizy i modelowania systemów w rozumieniu organizacji. Dla kogoś mającego przywiązanie do analizy strukturalnej, opisany szkielet będzie zapewne dobrym narzędziem pracy. Przyznam jednak, że kojarzy mi się to z latami 90-tymi i pierwszymi narzędziami typu EJB ([[Enterprise Java Bean]]) i anemicznym modelem dziedziny.
Książka adresowana do programistów, sam tytuł to sugeruje. Warto ją kupić (programiści) bo bardzo wyczerpująco opisuje to, co nazywam "implementacją obiektowości". Samo nauczenie się (semantyka i syntaktyka) obiektowo zorientowanego języka programowania to mało, warto poznać na czym ta implementacja polega: czym jest obiekt, dziedziczenie czy kompozycja. Autor skupia się jednak na implementacji samej "obiektowości". Moim zdaniem książka jak najbardziej przydatna programistom, bo przykłady są ilustrowane kodem i diagramami UML. Jednak nie znajdziecie tam zbyt wiele o obiektowo zorientowanym opisie modelowanej rzeczywistości, czyli o biznesowym aspekcie programowania i projektowania. Z treści książki…
obiektowość jako panaceum na problemy programistów i programowania to w moich oczach jak najbardziej wpadka. Obiektowość jako skuteczne metoda analizy "świata" i jego modelowania to sukces, ale to tylko kontynuacja rozwoju ogólnej teorii systemów. Obiektowość dała tej teorii bardzo dobre narzędzie - obiektowe metody modelowania. Specyfikowanie wymagań w postaci czarnej skrzynki się nie sprawdza, statystyki porażek projektów są niezmienne od lat. Specyfikacja wymagań w postaci projektu jest niemalże doskonałe (ale tylko tak jak doskonały jest projekt).
Z uwagi na zainteresowanie moim projektem "demo" stworzyłem tę stronę. Tu będą się pojawiały informacje o kolejnych etapach tworzenia tego dokumentu. Powiadomienia o postępach będą wysyłane mailem do subskrybentów. Projekt Szachy ma na celu pokazanie na prostym przykładzie, toku analizy i produktów jakie tworzę w roli analityka i projektanta. Dokument ten może zawierać pewne braki (brak pewnych szczegółów) gdyż celem tego dokumentu jest zademonstrowanie zawartości tego rodzaju dokumentacji a nie szczegółowe opracowanie realnego projektu, będzie to jednak zaznaczone w treści. Kliknij i pobierz aktualny plik projektu Wszelkie pytania i sugestie na temat treści projektu…
Książkę polecam przede wszystkim analitykom do nauki ale także "wyżartym" programistom, by sobie uporządkowali zdobyte doświadczenie i możliwie łagodnie przechodzili od metod strukturalnych do obiektowych. Tu pewnie nowinka dla nich: bazy danych projektujemy na samym końcu, na etapie implementacji opracowanego kompletnego projektu obiektowego.
Właśnie dlatego analiza i wymagania powinny zawierać model dziedziny wraz z zaleceniami co do implementacji. Nie jest to dokument (ten model) dla sponsora projektu (w rozumieniu do czytania). Jego rola (wartość jaką wnosi do projektu) to minimalizacja ryzyka, że developer wykona coś czego nie chcemy.
Artykuł ten napisałem z dwóch powodów. Pierwszy to odpowiedz na cytowaną tezę pod artykułem o radarach laserowych rodem z mojej Alma Mater (WAT). Sugeruję kierowcom nie używać na drodze prostych heurystyk tylko przestrzegać znaków drogowych, z dwojga złego lepiej zwolnić na źle oznakowanej jezdni niż kogoś zabić lub okaleczyć. Drugi to przestrzec przed prowadzeniem analiz wymagań metodą wywiadów wierząc, że "skoro klient mówi to wie i tak chce", bi niestety w większości przypadków jest to nieprawda.
Swego czasu na jednej z konferencji o analizie wymagań, mówiłem o potrzebie zrozumienia funkcjonowania analizowanej organizacji (firmy):...wszystko to co nas otacza, samo w sobie jest naturalnie proste. Złożone są, nie poszczególne rzeczy, a to, że jest ich wiele i mają na siebie wzajemny wpływ. Pamiętajmy, że jedna z najtrudniejszych gier na świecie ? szachy ? to tylko kilkanaście figur i proste reguły ich przemieszczania. Nawet największą organizację można, w toku analizy, rozłożyć na skończoną liczbę ról i reguł ich postępowania i zrozumieć jej funkcjonowanie. (żr. Jarosław Żeliński, referat na konferencji o systemach ERP).Analiza biznesowa to etap opisu (zrozumienia) modelowanej organizacji (modele procesów itp.). Potem, powstaje model rozwiązania, którym jest nie raz własnie oprogramowanie, jego logika (patrz powyższy cytat) to "obiektowy model dziedziny systemu", a nie jakiś diagram klas nafaszerowany atrybutami i pozbawiony operacji bo jest dokładnie odwrotnie...
Swego czasu pod artykułem Business Model vs. System Model, wywiązała się dyskusja, po tym jak napisałem, że oprogramowanie reprezentuje narzędzie pracy, więc projekt tego oprogramowania raczej powinien zawierać pojęcie (klasę) Karteka Pracowników a nie Pracownicy. Jeden z czytelników napisał wtedy (dociekliwym polecam w tym momencie cała tę dyskusje pod artykułem):... byt Pracownik jak najbardziej ma sens. Przecież tu jest zdefiniowane jego zachowanie (część jedynie z real world, ale jednak). Pracownik.pijeKaweRano().. przeciez nie KartotekaPracownika.pijeKaweRano() (Business Model vs. System Model).Gdzie problem?[...]No więc dlaczego nie podoba mi się klasa Pracownik? Bo pracownik to Aktor Systemu, a System ten przechowuje wybrane dane o tym pracowniku. Są to dane potrzebne np. do identyfikowania osób wystawiających dokumenty z Systemu, a do tego potrzebne są jedynie Karty Pracowników a nie Pracownicy. System (oprogramowanie) zastąpił papierowe Kartoteki Magazynowe dlatego są one teraz w Systemie, ale towary są w nadal magazynie 9a nie w Systemie), system "ma w środku" Kartę Towaru (zastąpiła papierową) zawierająca opis towaru i jego ilość w magazynie. Kartoteka Magazynowa to pudło zawierające Karty Towarów. Faktura VAT to obiekt w systemie, można ją wydrukować lub wysłać jej egzemplarz w postaci elektronicznej kontrahentowi.