Czy analityk systemowy tworzy system?

I bynajmniej pytanie nie jest emanacją wątpliwości, czy analityk systemowy pracuje nad systemem informatycznym. Pytanie dotyczy produktu pracy analityka systemowego, czyli czy to, co wytworzy spełnia definicję systemu.

system [gr.],  zespół wzajemnie sprzężonych elementów, spełniający określoną funkcję i traktowany jako wyodrębniony z otoczenia w określonym celu (opisowym, badawczym, do innego zastosowania — np. systemem jest proces technologiczny).

Źródło: Encyklopedia PWN

A spełniać powinien, gdyż dalsza transformacja do projektu (jeśli taki jest tworzony), a potem do kodu powinna płynnie wzbogacać system o kolejne szczegóły, finalnie tworząc system informatyczny. Można byłoby powiedzieć, że system analityczny powinien być przekształcony w ewentualny system projektowy, następnie w system programistyczny, by kolejną transformacją uzyskać system informatyczny. Przenosząc to na koncepcję MDA (Model-Driven Architecture), myślimy o transformacjach PIM do PSM, PSM do kodu, no i oczywiście kodu do elementów wykonywalnych.

No dobrze, ale skąd w ogóle taki temat? Ano jest efektem dzisiejszej dyskusji mejlowo – telefonicznej związanej z wczorajszym wpisem o opisie mikrousług w kontekście poziomów modeli relacyjnych baz danych. Będąc bardziej konkretnym, dyskusja dotyczyła wątpliwości, czy tego typu rozwiązanie można w jakikolwiek sposób wkomponować w treści historyjek (user story) i jaki będzie tego koszt.

Dyskusja

Dyskusja rozpoczęła się od krótkiego przedstawienia procesu wytwórczego zaadaptowanego w firmie, które skrócie można byłoby określić jako Agile z próbą silnej rozbudowy klasycznych artefaktów tego podejścia o różne elementy pochodzące z metodyk bardziej ukierunkowanych na modelowanie. Na pytanie, na ile takie podejście sprawdza się w praktyce, uzyskałem odpowiedź, że coraz gorzej, gdyż z jednej historyjki są coraz bardziej rozbudowane i jako elementy jednostkowe są bogate w informacje, ale z drugiej, im większe jest tworzone rozwiązanie, tym trudniej jest analitykom zapanować nad spójnością całości, W trakcie rozmowy usłyszałem o wielu cechach tego typu podejścia, ale jedna, z punktu widzenia niniejszego wpisu, wydała mi się bardzo ciekawa. Jest nią mianowicie spostrzeżenie, iż coraz częściej, analitycy muszą przeglądać dziesiątki historyjek, by zidentyfikować wpływ nowego oczekiwania na aktualny stan systemu. Nie ma bowiem jednego miejsca, w którym analitycznie byłby opisany docelowy sposób funkcjonowania rozwiązania informatycznego w zakresie, w który ingeruje oczekiwanie.

Podobne problemy osobiście zaobserwowałem w kilku projektach i mam wrażenie, że w skali IT można je uznać za występujące zauważalnie często. Jaka jest tego przyczyna?

Powróćmy do definicji pojęcia system i zastanówmy się nad pierwszą jej częścią. System jest to „zespół wzajemnie sprzężonych elementów. spełniający określoną funkcję […]”. W jaki sposób ten fragment definicji można przenieść na typowy proces produkcyjny oprogramowania oparty o modelowanie.

Można byłoby uznać, że zespół to model tworzonego rozwiązania informatycznego. Jaką spełnia funkcję? Opisuje propozycję wytwarzanego rozwiązania informatycznego na poziomie niezależnym od docelowej platformy (określenie platforma, którego używam, pochodzi z koncepcji MDA). Elementy to wystąpienia poszczególnych rodzajów konstrukcji, zdefiniowanych w językach modelowania wykorzystywanych do opisu propozycji rozwiązania a wzajemne ich sprzężenie (powiązanie) jest wypadkową języków modelowania oraz stosowanej metodyki.

W jaki sposób powstaje ten system? Jest efektem analizy wymagań i ich przełożenia na propozycję docelowego rozwiązania, reprezentowanego tym systemem.

Jak to wygląda w przypadku podejścia, o którym rozmawialiśmy? Wydaje się, że w tym przypadku, także mamy do czynienia z systemem, ale dużo bardziej odzwierciedla on system pracy, niż spójną propozycję docelowego rozwiązania. Jeśli spojrzymy na historyjki „obrabiane” w sprintach, to biorą one pod uwagę przede wszystkim zdolności realizacyjne zespołu w jednostce rozliczeniowej jaką jest na przykład sprint. Innymi słowy, zestaw to opis sposobu realizacji prac nad rozwiązaniem, element to jednostkowe zadanie podejmowane przez określonego członka zespołu a wzajemne ich sprzężenie, to zależności łączące elementy, pozwalające realizować pracę zgodnie z przyjętą metodyką zwinną.

Podsumowując, w obu przypadkach analityk systemowy tworzy system, natomiast osobną kwestią jest to, który z nich jest skuteczniejszy i efektywniejsze w dłuższej perspektywie czasu pracy analityka systemowego, a w konsekwencji, całego zespołu.

Wnioski

Można byłoby uznać, iż efektem tej dyskusji jest wniosek, że albo stosujemy podejście oparte o modelowanie, albo podejścia zwinne. Ale byłoby to zbyt duże uproszczenie. Gdybyśmy bowiem uznali, że docelowym efektem pracy analityka jest system będący modelem (tak jak docelowym efektem pracy programisty jest kod, a testera – skrypty) a przyrost zawartości modelu byłby efektem przyjętych do realizacji jednostkowych zadań, reprezentowanych na przykład jako historyjki i stanowiących element systemu pracy to stworzylibyśmy dwa ortogonalne systemy, które wzajemnie się wspierają i z których każdy ma do spełnienia określoną, unikalną funkcję (swoisty przykład Separation of Concerns). Dzięki temu, analityk systemowy tworzyłby system bezpośrednio transformowany do systemów kolejnych faz procesu produkcyjnego, a praca mogłaby być prowadzona w „zwinnym duchu”.

Czy da się stworzyć takie podejście? Da się. Czy stosowałem? Stosowałem. I twierdzę, że ma sens, jeśli jest właściwie opracowane.

To była całkiem ciekawa dyskusja, na której krótkie streszczenie otrzymałem zgodę i za którą dziękuję.

Grafika: Freepik

Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.