Zależnie od szacunków (czyli od tego jak zdefiniowano sukces) 60 – 80% projektów IT to nieudane projekty.

Pod pojęciem projektu IT rozumiemy tu systemy dla firm: szeroko pojęte systemy biznesowe. Na świecie każdego dnia inicjowanych są setki tysięcy projektów IT dla firm, śladowe ilości nowych gier i w zasadzie żaden nowy system operacyjny (co najwyżej jego drobne rozszerzenia i aktualizacje). Dlatego nie ma sensu by w projektach biznesowych stosować wzorce i metody sprawdzone w tworzeniu gier czy środowisk technologicznych. Dlatego zlecanie projektów biznesowych od razu deweloperom ma bardzo nikłe szanse powodzenia.

Aplikacja vs jej platforma

Czym jest biznesowa aplikacja (software) a czym stos technologiczny (gry pomijamy w tych rozważaniach)? R.C Martin [Robert C. Martin (with Grenning, J., & Brown, S.). (2018). Clean Architecture: A craftsman’s guide to software structure and design. Prentice Hall. https://raw.githubusercontent.com/sdcuike/Clean-Code-Collection-Books/master/Clean%20Architecture%20A%20Craftsman’s%20Guide%20to%20Software%20Structure%20and%20Design.pdf] tak to przedstawia:

Granica Software-OSAL (tu Software=Application): aplikacje przetwarzają dane, stos technologiczny jest tylko środowiskiem dla tego przetwarzania [Cockburn, A. (2005, January 4). Hexagonal architecture. Alistair Cockburn. https://alistair.cockburn.us/hexagonal-architecture/]:

Popatrzmy na te setki tysięcy stale inicjowanych nowych projektów biznesowych: stos technologiczny, jako platforma, stale ten sam (kilka do wyboru od dekad). Zestawienie setek projektów biznesowych pokazuje, że:

• wymagania pozafunkcjonalne w zasadzie są takie same dla każdego projektu,
• wymagania funkcjonalne to kluczowy cel każdego projektu IT (nikt nie wydaje pieniędzy tylko po to by sie gdzieś zalogować, dlatego logowanie nie jest “przypadkiem użycia aplikacji”).

Funkcjonalności

Czym są “wymagania funkcjonalne”? To jedyne powody, dla których te aplikacje powstają lub są kupowane. Nikt nie twierdzi, że “stos technologiczny” jest niepotrzebny, owszem bez niego żadna aplikacja nie zaistnieje. Problem w tym, że stos technologiczny nigdy nie jest problemem ani powodem porażki projektu, są nim niespełnione wymagania funkcjonalne. Wymagania funkcjonalne to to co wpisujemy na ekranie i na nim potem oglądamy, oraz mechanizm przetwarzania tych danych.

Problemem jest zrozumienie i opisanie tego mechanizmu, bo implementacja projektu (kodowanie) nigdy nie była problemem. W 1997 roku [Rosenberg, D., & Scott, K. (1999). Use case driven object modeling with UML. Springer.] jako jeden z wielu opisał to Rosenberg:

Eric Evans w swojej książce [Evans, E. (2014). Domain-driven design: Tackling complexity in the heart of software. Addison-Wesley.] także wskazuje na to, że na etapie projektowania realizacji funkcjonalności pomijamy środowisko. Funkcjonalnosci to treść i logika jej przetwarzania:

Powyższy diagram wskazuje, że mamy Smart UI (dla usera) a za nim model realizacji wymagań funkcjonalnych: serwisy (przetwarzanie), obiekty danych (to są nośniki treści) oraz treści (value object).

Warto tu zwócić uwagę na ważny fakt z naszej rzeczywości: mało co ma w realnym świecie tożsamość i na tym “wykłada się” większość projektów i wdrożeń opartych na relacyjnych modelach danych: tu wszystko musi mieć tożsamość bo relacje między tabelami są budowane na kluczach (tożsamość). Co ciekawe pojęcie Value Object pojawia sie także w specyfiakcji UML (Values, UML, v.2.5.1., 2017, str. 69).

Wzorcem podobnym do DDD, ale prostrzym i starszym, w moich oczach jednak bardziej popularnym, jest BCE znanym do lat 90-tych, opisanym między innymi przez Larmana [Larman, C. (2005). Applying UML and patterns: An introduction to object-oriented analysis and design and iterative development (3rd ed). Prentice Hall PTR, c2005.]:

Cechą wspólną tego co piszą Larman, Evans i Rosenberg, jest separacja interfejsów, logiki przetwarzania treści i jej utrwalania (teza , że “paradygmat obiektowy” to łączenie danych i funkcji w obiekty, jest fałszywa na co już 30 lat temu zwracał uwagę Alan Kay, prekursor obiektowości w inżynierii oprogramowania).

Biznes czyli co

Biznes to treść grupowana w dokumenty i zapisana jako dane, i tu mamy problem bo liczby stanowią obecnie znikomą część danych: komputery dzisiaj w zasadzie nie liczą (operacje na poziomie procesora to nie to) a przetwarzają teksty.

Dlatego, jak zwraca uwage Rosenberg, zaczynamy od ustalenia tego co i po co chce zobaczyć użytkownik [źr. grafiki: While sketches, wireframes, mockups and prototypes may be similar, they serve different purposes

Mockups]:

Na czym więc polega analiza biznesowa i projektowanie oprogramowania?

Komputer to maszyna do przetwarzania danych. To co robi jest determinowane procedurami. Oprogramowanie to nic innego jak zestaw procedur, te przetwarzają treści, nośnikiem tych treści są formularze, dokumenty, komunikaty (te trzy pojęcia to tu synonimy).

Czym są funkcjonalnności? To problemy do rozwiązania. Np.:

system powinien pozwalać na monitorowanie fakturowania zamówień

Czy to jakis problem bazodanowy? Nie. To problem polegający na takim zaprojektowaniu formularzy by było to możliwe. Jak? Należy na formularzu Faktura umieścić pole Nr Zamówienia oraz zagwarantować by procedura tworzenia nowej faktury wymuszła użycie do tego okreśłonego Zamówienia.

Jak się do tego zabrać? Skuteczne postępowanie znamy od dawna:

1. zbierz dokumenty operacyjne
2. zbuduj na ich podstawie model procesów biznesowych i przepływu dokumentów w całej firmie (rzecz w tym tym by niczego nie pominąć)
3. przeprowadź optymalizację procesów i standaryzację struktur dokumentów (najważniejsze: nie informatyzuj bałaganu)
4. ustal zakres projektu (obszar informatyzacji), zbierz potrzeby (wymagania)
5. zaprojektuj realizację wymaganej funkcjonalności, przetestuj projekt
6. zleć implementację
7. wróć do pk.t 5. jeżeli są kolejne wymagania

Pętlę, opisana punktami od 4. do 7., jako “Validation V-model” ładnie niedawno opisał Alistair Cockburn (sygnatariusz Agile Manifesto):

Model procesów biznesowych

Kluczem jest model organizacji zwany często Architektura Korporacyjna i przedstawiany w postaci piramidy złożonej z trzech poziomów: najniższy to poziom materialny, dwa powyższe to abstrakcje czyli modele:

Model procesów biznesowych to nie są setki ikonek BPMN na płachtach wielkości ściany gabinetu prezesa. Przydatny model procesów biznesowych to opracowne w narzędziu CASE kilkanaście (kilkadziesiąt) powiązanych ze sobą, skomentowanych, diagramów wielkości katki A4 każdy. Przydatna dokumentacja projektowa to ok. 100 stron [https://www.boc-group.com/en/blog/ea/designing-operating-models/]:

Skuteczny projekt informatyczny to proces:

1. analiza biznesowa (notacja BPMN)
2. specyfikacja wymagań (np. notacja SysML diagram wymagań)
3. projektowanie rozwiązania (UML, wzorce projektowe)
4. kodowanie (implementacja, deweloper wybiera technologię i koduje)
5. wdrożenie pod nadzorem autorskim projektanta

Całość w pętlli SDLC i wygląda tak:

Porównajmy powyższe z podstawowym diagramem używanym do udokumentowania zakresu projektu jakim jest diagram przypadków użycia UML:

Na obu powyższych diagramach po lewej są ludzie a po prawej projektowany system IT, i nie jest to tu przypadkowa zbieżność 😉

Dlaczego więc projekty IT tak często się nie udają?

Bo nadal większość od razu startuje z punktu 4. z powyższego procesu, a to ma bardzo nikłe szanse powodzenia, co pokazują statystyki. Efekt? Stos technologiczny szybko dostarczony, funkcjonalności nadal w toku…

(artykuł opublikowany także na LinkedIn)