Tak, taką książkę można nabyć na Amazonie ;). Streszczenie na stronach sprzedawcy oddaje dobrze jej treść:

This book provides a basic, conceptual-level description of engineering management disciplines that relate to the development and life cycle management of a system. For the non-engineer it provides an overview of how a system is developed. For the engineer and project manager it provides a basic framework for planning and assessing system development.

Ogólnie książka opisuje podstawowy koncepcyjny etap inżynierii systemów (i nie należy tego utożsamiać tylko z branżą IT). Jest napisana przystępnym językiem, adresowana  głównie dla managerów (pierwsze części) by zapoznać ich z inżynierią systemów i systemowym podejściem. Kierownikom projektów “pokazuje” czym (ewentualnie ;)) zarządzają.

Tu tylko kilka słów. Najpierw po raz kolejny cytat:

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.

A teraz diagram obrazujący “proces inżynierii systemowej” na bazie jednej z ilustracji w tej książce:

Mamy tu trzy kluczowe etapy, powiązane iteracyjnie:

1. Analiza wymagań, chodzi tu o wymagania biznesowe.
2. Analiza funkcjonalności, chodzi tu o ustalenie do jakich “rzeczy’ system jest potrzebny (przeznaczony).
3. Projektowanie czyli próba opracowania konstrukcji, mechanizmu działania tego systemu.

Trzeci punkt to właśnie klucz do sukcesu: zanim zaczniemy konstruowanie (np. pisanie kodu) warto opracować to rozwiązanie ‘na papierze”. To po pierwsze pozwala uniknąć ogromnych kosztów “rozpoznania bojem” a po drugie daje jako produkt bardzo dobrą (na wysokim poziomie abstrakcji ale kompletną) dokumentację działania systemu.

Niedawno cytowałem artykuł o porażce systemu e-border, tym razem innych cytat:

The Home Office had a concept, not a well-developed set of requirements. Concepts need a reality check; otherwise, you could be chasing a dream! Even though the program ran a pilot to evaluate the feasibility of the concept, the National Audit Office report (2015) claims that it did not cover all aspects of the solution. Consequently, the programme was executed with an untested concept and unknown requirements, which led to disputes. (Źródło: Blueprints Are Not Requirements!)

Jedną z głównych przyczyn porażki było rozpoczęcie realizacji projektu wyłącznie na bazie wizji, bez jakichkolwiek analiz i projektowania tego “co na prawdę ma powstać i w jakich warunkach”. Patrząc na zobrazowany powyżej proces inżynierii systemowej wykonano wyłącznie pierwszy etap (wymagania biznesowe) i przystąpiono do realizacji projektu bez jakichkolwiek analiz i projektowania, od razu zaczęły powstawać prototypy… Projekt e-border zakończył się spektakularną porażką.

Jedną z notacji OMG jest SysML. Jest to dedykowany dla inżynierii systemów profil UML. Odnosząc się do procesu inżynierii systemowej powyżej, powstają w tej notacji kolejne diagramy:

1. diagram wymagań (lub ich specyfikacja),
2. diagram przypadków użycia i ich specyfikacja,
3. model dziedziny (mechanizm działania systemu: diagramy komponentów, klas i obiektów) oraz modele zachowania systemu (diagramy sekwencji, komunikacji, scenariusze przypadków użycia).

Powyższe to wymagane minimum dla poprawnego wyspecyfikowania systemu zanim powstanie choć jeden wiersz kodu czy wykop pod fundament.

Z informacji jakie posiadam, od lat rząd USA nie ponosi takich spektakularnych porażek projektowych jak europejskie rządy, jednak w przypadku projektów korporacyjnych już tak różowo nie jest :), wpadki mają wszystkie:

According to an often-quoted study from the Gartner Group, 75% of IT projects fail. The Standish Group conducts an annual survey of IT projects. Their latest report shows a decrease in project success rates.

1. 32% of all projects succeeded: delivered on time, on budget, with required features.
2. 44% were challenged: late, over budget, and/or with less than the required features.
3. 24% failed: cancelled prior to completion or delivered and never used.

When we look back, we not only see failures but can clearly see the boom the software industry has been given with its success. But the worrying aspect is that there are failures that are recurring every year, maybe in a different organization but mostly with common causes. (Źródło: Blueprints Are Not Requirements!)

Polecam książkę 😉

Systems Engineering Fundamentals Kindle Edition by United States Government US Army (Author) (Źródło: Amazon.com: Systems Engineering Fundamentals eBook: United States Government US Army: Kindle Store)

Dwa lata temu pisałem o tym, czym jest, po co się prowadzi i jak, studium wykonywalności projektu:

W literaturze można spotkać różne ?definicje? studium wykonalności, jednak ta którą opisałem, zdaje się być najbliższa definicji, którą przytoczyłem na początku: bazującej na znaczeniu słownikowym. Praktyka pokazuje, że intencje sponsorów tych analiz są z nią zbieżne: celem jest podjęcie decyzji o najmniejszym ryzyku w świetle posiadanej na dany temat wiedzy. Definicje bazujące na technicznej i finansowej wykonalności danego projektu, są spotykane dość często i w literaturze i na stronach wielu instytucji. Metoda prowadzenia takich analiz, bazująca na modelowaniu czyli na analizie systemowej,  wydaje się być jednak najwłaściwszą. (Źródło: Studium wykonalności ? czym naprawdę jest | | Jarosław Żeliński IT-Consulting)

W artykule tym zwracałem uwagę na wartość modelowania (a nie rysowania…), wartością tą jest testowanie koncepcji. Sama koncepcja nie jest żadnym wymaganiem, co ilustruje świetny artykuł na stronach Modernanalyst.com:

Requirements must be based on facts and real-life scenarios. When the concept is untested or not fully tested, then the requirements are hypothetical. Moving to design and build with hypothetical requirements, the design and/or build phase becomes the testing ground for the concept. This may lead to clashes as each party has different expectations of the outcome of the ?hypotheses?.

Źródło: Blueprints Are Not Requirements!

Powyższy diagram pokazuje główne przesłanie opisanej metody, która jest zgodna w 100% z pełną analizą systemową: pierwszy etap to opracowanie koncepcji czyli hipotezy mówiącej “taki system jest nam potrzebny” do rozwiązania problemu biznesowego (potrzeby biznesowe).  Kolejny etap to stwierdzenie poprawności pomysłu, to nic innego jak studium wykonalności, testowanie pomysłu. Tu ważna rzecz: test musi być prowadzony w oparciu o fakty i tylko fakty, innymi słowy model nie może kolidować z rzeczywistością, musi także pokazać, że zaprojektowany nowy lub zmieniony mechanizm działania organizacji da oczekiwane efekty. Dopiero gdy hipoteza mówiąca, że “taki system realizuje nasze potrzeby” zostanie potwierdzona testami na modelu, ma sens opracowywanie wymagań na to rozwiązanie. W toku opracowywania wymagań, także je testujemy. Tu znowu sprawdza się skuteczność podejścia “projekt (model) jako wymaganie”.

 

Trzy lata temu opisałem cały taki proces, na dość może trywialnym przykładzie (szachy), ale za to (mam nadzieję) przejrzystym. Na zakończenie artykułu zwróciłem uwagę, że:

Analiza i projektowanie obiektowe (ang. OOAD) to niejako ?implementacja? klasycznej analizy systemowej. Nie ma ona nic wspólnego ze strukturalnymi metodami analizy i projektowania oprogramowania (czego wielu zdaje się nadal nie dostrzegać).  Wygląda na to, że jest znacznie trudniejsza ale praktyka pokazuje, że daje znacznie lepsze rezultaty. Języki obiektowe to nie jakaś tam nowa nazwa klasy na podprogramy, a zupełnie nowy paradygmat programowania: musi być poprzedzany analizą i projektem. Jego zaletą jest to, że pozwala na odwzorowywanie, niemalże jak w grze, analizowanego i rozwiązywanego problemu, pozwala na przetestowanie pomysłu na program zanim powstanie choć jedna linia programu. Problemem i wyzwaniem na etapie analizy jest zrozumienie problemu,  co mam nadzieję pokazałem. Niestety wiele analiz dokumentowanych z użyciem notacji UML nie ma wiele wspólnego  z OOAD, stanowią echa strukturalnych metod analizy i projektowania, stosowania baz relacyjnych już na etapie analizy (obiektowe narzędzia nie czynią projektów obiektowymi). Niestety błędy te popełniają nawet wykładowcy wielu uczelni i kursów. (Źródło: Plansza do gry w szachy czyli analiza i projektowanie | | Jarosław Żeliński IT-Consulting).

Autor artykułu przywołuje niezmienną od lat statystykę:

According to an often-quoted study from the Gartner Group, 75% of IT projects fail. The Standish Group conducts an annual survey of IT projects. Their latest report shows a decrease in project success rates.

1. 32% of all projects succeeded: delivered on time, on budget, with required features.
2. 44% were challenged: late, over budget, and/or with less than the required features.
3. 24% failed: cancelled prior to completion or delivered and never used.

When we look back, we not only see failures but can clearly see the boom the software industry has been given with its success. But the worrying aspect is that there are failures that are recurring every year, maybe in a different organization but mostly with common causes. (Źródło: Blueprints Are Not Requirements!)

…i zwraca uwagę, że ich przyczyny są od lat stale takie same…

“Requirements must be based on facts and real-life scenarios.” (wymagania muszą być oparte na faktach i realnych scenariuszach).  Więc ile warte są wizje w projektach agile albo wydumane w toku warsztatowych burz mózgów litanie życzeń i pomysłów? Nie tylko moim zdaniem: nie są wiele warte i nie powinny być wymaganiami.

Skróty te oznaczają odpowiednio (w j.ang): Business Process Management oraz Business Process Management Software. Budzą one wiele nieporozumień i niezrozumienia. Pierwsze to “Zarządzanie procesami biznesowymi” rozumiane jako działalność związana z zarządzaniem organizacją. Drugie to “Oprogramowanie [służące] do zarządzania procesami biznesowymi” czyli jakaś aplikacja, której wewnętrzne działanie jest opisane procesami.

Ten wpis zapewne wywoła wiele kontrowersji, gdyż opisuję tu przyczyny, dla których moim zdaniem, systemy BPMS nie tworzą wartości dodanej. Nie widzę sensu ich stosowania w wersji “process engine”, moim zdaniem nie zastąpią nawet części “typowych aplikacji”.

Ale po kolei… Niedawno po raz kolejny zostałem zapytany o… no własnie. O co?

[czytelnik]:
Panie Jarosławie,
ostatnio zdarzyło mi się przejść przez parę elementarnych pytań, które przez wielu są pomijane. Wszyscy mówią o szerokim spojrzeniu na biznes, o projektowaniu procesów, zależności pomiędzy nimi. Racja. To wszystko da się zrobić np. w Visual Paradigm. Później jednak chciałbym przejść do BPMS i powołać do życia jeden z opisanych wcześniej procesów. Jak utrzymać relację pomiędzy modelem procesów np. w Visual Paradigm, a tym co się dzieje w silnikach procesowych?

Jarosław Żeliński:
Przede wszystkim warto pamiętać, że:
– środowiskiem (kontekstem) dla modeli analitycznych procesów  (non-executable w BPMN) jest modelowana organizacja (w tym kontekście pule na modelu współpracy są organizacjami),
– środowiskiem (kontekstem) dla maszynowych modeli procesów (executable) jest serwer BPMS (tu na modelu współpracy pulami są serwery BPMS, “motory procesów”).

Powyższe powoduje, że dany model albo jest biznesowy albo maszynowy (wykonywalny). Często jest tak, że jedna firma (organizacja) ma tylko jeden serwer BPMS, ale im większa firma tym bardziej prawdopodobne, że będzie ich więcej (np. oddziałowe).

Tak więc pierwszy krok to zadeklarowanie jaki kontekst mają dane modele (ich system z dekompozycją). Jeżeli zadeklarujemy, że tworzymy modele wykonywalne, to w strukturze modeli trzeba trzymać dyscyplinę precyzji modelowania by ich eksport np. do XPDL generował poprawne pliki.

[czytelnik]:
Chodziło mi o podejście BPM (jako sposób zarządzania firmą) i o wykorzystanie narzędzi informatycznych. W narzędziach BPMS nie ma możliwości zobrazowania wielu modeli procesów oraz śledzenie zależności między nimi. Musimy to robić w innym narzędziu. Z Pana wypowiedzi wynika, że jeżeli nie wykorzystujemy żadnego innego narzędzia oprócz BPMS, to nie jest możliwe modelowanie całościowego obrazu przedsiębiorstwa. Co jeżeli klient chce wprowadzać BPM (świadomie) i zaczyna od 1,2 procesów – kończy na 50 procesach. Powinienem utrzymywać dodatkowo architekturę w VP? Czy trzymać po prostu odrębne procesy w BPMS?

Jarosław Żeliński:
Teraz (chyba) rozumiem, pozostaje podzielić to na dwa projekty (modele):
– analiza i modelowanie procesów w firmie (tu BPM rozumiany jako zarządzanie),
– wymagania na oprogramowanie worlflow (tu BPMS jak aplikacja).

Pierwsze to modele analityczne, wielopoziomowe itp.. procesów biznesowych. Drugie to diagramy przypadków użycia (UC) dla BPMS i procesowo (modele wykonywalne) opisana implementacja tych UC z użyciem BPMS.

Nie da się tego semantycznie modelować na jednym spójnym modelu procesów.

[czytelnik]:
Jeżeli chcę modelować szerszy kontekst organizacji (wiele powiązanych procesów, top-down), to muszę użyć CASE i nic innego. Czyli do wdrożenia BPM (jako stylu zarządzania firmą) muszę wykorzystać CASE (bo chcę i muszę mieć szeroki obraz). Błędem jest myślenie i pisanie o wykorzystaniu w tym celu BPMS – widziałem dziesiątki artykułów o tym, że prawdziwy BPM bez BPMS nie istnieje, że są nierozłączne. BPMS jako tworzenie konkretnej aplikacji opartej na wybranej perspektywie procesowej jest po prostu wynikiem analizy wykonanej przy użyciu CASE. Nie ma relacji ani bezpośredniego przełożenia CASE na BPMS. Można oczywiście próbować importować, exportować, ale to zawsze wiąże się z ryzykiem pogubienia informacji bądź przyrządzenia pięknego spaghetti. Sprowadza się to do tego, że aktualizacja i utrzymanie procesów w dwóch narzędziach jest bardzo pracochłonne i nikt zapewne tego nie robi:). Wizerunek CASE-owych narzędzi traci trochę uroku w tym kontekście 😉

Jarosław Żeliński:
Nie tylko moim zdaniem błędem jest utożsamianie BPM z BPMS, pierwsze to strategia wewnętrzna firmy drugie to aplikacja. Zresztą, każda aplikacja realizuje jakieś swoje wewnętrzne scenariusze, drugorzędne znaczenie ma to czy to motor BPMN czy nie… (wiele systemów BPMS korzysta z własnych, innych innych niż BPMN, notacji).

Co do uwagi o przydatności narzędzi CASE, nie zgodzę się. Jest bezpośrednia relacja BPM a BPMS: aktywności w modelach procesów organizacji (BPM) to przypadki użycia aplikacji BPMS, te są niczym innym jak “zadaniami użytkownika” w BPMN. VP radzi sobie z tym bardzo dobre, jednak wymaga to poprawnego modelu systemowego a konkretnie oddzielnego modelowania organizacji i oddzielnego aplikacji i jej wewnętrznego mechanizmu działania. To razem można “śladować” ale trzeba zbudować sobie dobry szkielet dla całości.

 

Tyle dyskusja. W czym problem? Najpierw po raz kolejny model warstwowy SOA:

Na najwyższym poziomie mamy modele procesów biznesowych (Business Proces, obecnie modelowane z reguły z użyciem diagramu procesów notacji BPMN i reguł biznesowych), niżej abstrakcje usług (Business Services, modelowane z użyciem przypadków użycia UML), dalej komponenty aplikacyjne (Components, obecnie modelowane z użyciem diagramu komponentów UML). Zasoby operacyjne (Operational Resources, na samym dole), obecnie modeluje się je z użyciem diagramów wdrożenia UML.

Tak więc to co nazywamy BPM, to zarządzanie organizacją. Tu modelujemy procesy biznesowe w rozumieniu “modelujemy mechanizm działania organizacji”. Część aktywności w tych procesach będzie (jest) wspierana aplikacją (jej usługami). Od tego momentu możemy, rozpoczynając od przypadków użycia, zacząć modelować aplikację (wymagania na nią) idąc przez modele dziedziny, scenariusze aż do podziału na komponenty. Możemy także wybrać inną drogę: oprogramowanie BPMS i zacząć modelować logikę wymaganej aplikacji z użyciem notacji BPMN i tak zwanych diagramów wykonywalnych. Na tych diagramach pojawią się “niskopoziomowe” zadania (skrypt, wysłane komunikatu, itp.) oraz “zadania użytkownika” (user task w BPMN), ktore są interakcją tej aplikacji z jej użytkownikiem.

Drugie podejście ma pewną wadę: absolutnie nie usuwa potrzeby napisania kodu logiki biznesowej (np. naliczenie upustu, scoring kredytobiorcy itp.) dla zadań BPMN typu “business rule”. Dlatego nie wróżę sukcesu rynkowego tego typu aplikacjom (BPMS). Stawiam raczej na dalszy rozwój typowych aplikacji biznesowych oraz systemów typu “task management” z wbudowanymi “motorami reguł biznesowych”. Niestety systemy BPMS nie zwalniają z konieczności napisania kodu logiki biznesowej i przechowywania danych, za to dodatkowo komplikują cały proces dostarczenia oprogramowania potrzebą pośredniego tworzenia wykonywalnych modeli BPMN.

Owszem można podejmować próby by pierwsze trzy warstwy SOA ująć “w jednym modelu”, jednak pojawi się problem zarządzania kontekstami (biznesowy i maszynowy) w ramach jednego modelu. Opis tego podejścia można znaleźć na blogu Bruce Silver’a:

One of the singular successes of BPM technology is a common language ? BPMN ? used both for process modeling and executable design.  At least in theory?. (Źródło: Process-Driven Applications: A New Approach to Executable BPMN – Business Process Watch)

 

Co do tego czy aplikacje CASE radzą sobie z tym… aplikacje te bez problemu, ale każdy projekt wymaga niestety indywidualnego podejścia.

Tym razem antykwariat :). Książka leży u mnie niemalże od dnia wydania czyli od roku 2004-go:
Podstawy techniczne inżynierii oprogramowania (Dick Hamlet, Joe Maybee, WNT Warszawa 2003).

Przypomniałem sobie o niej gdy student poprosił o zalecaną literaturę. Zaryzykuję tezę, że to lektura obowiązkowa każdego analityka biznesowego projektanta (tak, analityk biznesowy to także projektant, odkrywca i projektant logiki biznesowej aplikacji).

Książka zawiera cztery części:

1. Inżynieria oprogramowania
2. Wymagania i specyfikacja
3. Projektowanie i kodowanie
4. Testowanie

Od razy zaznaczą, że mało tam o “suchym kodowaniu”. To była pierwsza książka, która otworzyła mi oczy na inżynierię tworzenia oprogramowania, kluczową role analityka, który jest projektantem, i zrozumienia tego czym jest tak zwany paradygmat obiektowy. Autorzy precyzyjnie i dobitnie zarazem opisują różnicę pomiędzy rzemiosłem a inżynierią…

Poniżej kilka słów o tworzeniu dokumentacji:

Gorąco polecam polowanie w antykwariatach… 🙂

 

Od 17-go kwietnia mamy wersje 13.1 pakietu Visual-Paradigm (i pełnej wersji dla analityków i projektantów: ArchiMetric). Twórcy pakietu bardzo silnie współpracują z analitykami w wielu krajach (należę do nich 😉 ) , zbierają sugestie ale też filtrują je.  Cieszy mnie to, że w przeciwieństwie do (jak obserwuję) firmy SPARX (producent Enterprise Architekta), nie wychodzą poza standardy. W VP odrzucają wszelkie formy niestandardowych pomysłów (np. aktor “czas” w Enterprise Architect to kuriozalna, niestandardowa konstrukcja) ale za to implementują sprawdzone pomysły na ergonomie pracy oraz zarządzanie spójnością projektu. Jeżeli to tego dodać zdrowe podejście do agile otrzymujemy kolejną odsłonę oprogramowania CASE, które z jednej strony wręcz doskonale wspiera standardy OMG, nie nagina ich, daje swobodę pracy z nimi (SPARX poszedł w masę gotowych wzorców, z którymi się walczy tworząc diagramy i jest wyjątkowo mało intuicyjny).

Ta odsłona zaowocowała jeszcze większą integracją metod zwinnych z formalizmem notacji, mam wrażenie, że ludzie w Visual-Paradigm mają przybitą na ścianie całą biblioteczkę Scott’a Amblera :). Poniżej przykłąd połączenia twardego modelowania procesów w BPMN z User Story, “sztandarowym” narzędziem w metodykach zwinnych. Po co? Ano po to, by panować nas “spójnością, kompletnością i niesprzecznością”. To narzędzie pozwalające połączyć zalety wymuszenia spójności, jaką daje użycia notacji BPMN i analizy systemowej z “kwiecistością” ludzkich produkcji “słowno-muzycznych” 😉 .  Robię tak od lat ale teraz narzędzie daje pełne wsparcie tej metodzie pracy.

Adhere User Stories to Any Diagrams User stories can now be written in any diagram, such as BPD. This allows you to relate users? concern and / or requirements in the form of a story card. Presented along with the system designs. In particular, the visual mapping between user stories and BPMN activities. Which will help to identify user stories based on a business process (diagram). Źródło: What’s New in Visual Paradigm 13.1?

Dla purystów (ja też nim jestem): nadal jest to zgodne z notacją BPMN, bo ta dopuszcza definiowanie własnych symboli z ich składnią i użycie ich na diagramach.

Cieszy mnie, że to narzędzie współtworzą praktycy dla praktyków, bez implementowania nieuzasadnionych pseudoteorii i wymuszania na użytkownikach jakichkolwiek “słusznych poglądów”.