Moją rolą w projekcie jest analiza potrzeb i opracowanie modelu mechanizmu ich realizacji a także architektury realizacji tego mechanizmu. Potem prowadzę nadzór nad realizacją.
Czy wdrożenia systemów IT z niezależnym nadzorem architekta znacznie rzadziej ponoszą porażki?
Tak, wdrożenia systemów IT z niezależnym nadzorem architekta wykazują wyższy wskaźnik sukcesu, ponieważ eliminują one błędy projektowe odpowiedzialne za znaczną część porażek projektowych. Chociaż ogólne statystyki sukcesu projektów IT są niskie – według raportów McKinsey tylko 0,5% projektów spełnia jednocześnie kryteria budżetu, czasu i korzyści biznesowych – to właściwa architektura stanowi fundament, który drastycznie zwiększa prawdopodobieństwo powodzenia. Oto kluczowe powody, dla których niezależny nadzór architekta redukuje ryzyko porażki:
Weryfikacja poprzez kodowaniem: Architekt może szybko budować prototypy w UML (Proof of Concept), dostarczając realnych dowodów na wykonalność rozwiązań, co jest skuteczniejsze niż opieranie się wyłącznie na kodzie.
Rola „bezpiecznika”: Niezależny architekt stanowi bufor między biznesową wizją klienta a technologicznymi możliwościami dostawcy, zapobiegając dominacji interesów integratora nad potrzebami organizacji.
Weryfikacja przed kodowaniem: Architekt potrafi zweryfikować założenia projektowe na wczesnym etapie, co drastycznie zwiększa prawdopodobieństwo sukcesu w porównaniu do projektów prowadzonych reaktywnie.
Fundament decyzji: Około 80% porażek projektów IT wynika nie z technologii, lecz z błędnych decyzji architektonicznych podjętych na początku. Brak nadzoru prowadzi do tzw. architektonicznego dryfu, zwiększając złożoność i dług technologiczny.
Redukcja błędów w fazie koncepcyjnej: Szacuje się, że nawet 40% przyczyn porażek IT (takich jak brak wymagań czy niewłaściwa technologia) leży w obszarze architektury. Błędy popełnione na tym etapie tworzą „niestabilny fundament”, którego nie jest w stanie uratować nawet najlepsze zarządzanie projektem.
Ograniczenie wpływu dostawcy (Vendor Lock-in): Częstym powodem porażek jest brak nadzoru nad wykonawcą, co daje mu niemal nieograniczone uprawnienia do kształtowania zakresu projektu pod własne korzyści, a nie realne potrzeby klienta. Niezależny architekt działa jako obiektywny doradca techniczny.
Zapobieganie „Scope Creep”: Niezależny nadzór pomaga kontrolować niekontrolowany rozrost zakresu prac (scope creep), który jest jedną z głównych przyczyn przekroczenia budżetów i terminów.
.
Analiza, projektowanie i nadzór
W projektach pełnie rolę analityka-projektanta oraz potem prowadzę nadzór autorski, a komunikacja w projekcie oparta jest na tak zwanej Żywej Dokumentacji on-line.
Żywa dokumentacja to serwer pracy grupowej. Standardowo używam Visual-Paradigm. Jeżeli zleceniodawca preferuje np. Jira czy Confluence to integruje się z tą platformą.
Co robi Analityk-projektant?
Ustala mechanizm działania aplikacji (ale nie jej środowiska) przed kodowaniem. Kodowanie to etap rozpoczynany po tym, jak wykażemy że mechanizm ten jest poprawny.
“In software development, a model is a representation of a system or process, while code is the actual instructions that make the system run. Models help clarify needs, define architecture, and analyse code, while code implements the final product. “
Przebieg projektu
Kadry kierownicze Sponsora projektu dostarczają materiały w postaci potrzeb biznesowych (wymagania biznesowe), na podstawie których powstaje projekt logiki działania aplikacji (model realizacji wymagań funkcjonalnych), którą realizuje (implementuje) SH/deweloper.
Standardowo analiza wymagań poprzedzana jest powstaniem analitycznego modelu firmy (workflow/docflow: procesy biznesowe) i dopiero na jego podstawie powstają wymagania biznesowe. Projekty w których biorę udział są prowadzone na bazie dwóch podstawowych wzorców i praktyk: V-Model oraz Architektura Heksagonalna.
V-Model to model pracy polegający na poprzedzaniu kodowania projektowaniem (rozwiązywanie problemu):
Jeżeli architektura aplikacji jest komponentowa (moduły) aplikacja powstaje iteracyjnie w modelu przyrostowym. Moja rolą jest opracowanie (projekt w notacji UML) lewej gałęzi powyższego modelu: to są analiza wymagań, projektowanie i nadzór nad całym zakresem: Requirement Analysis, System Design, Architecture Design (HLD), Modul Design (LLD).
Deweloper (prawa gałąź) dostarcza i konfiguruje środowisko oraz wykonuje implementację w technologii i środowisku które zaoferował (implementacja projektu aplikacji).
Czym jest Model Logiki Aplikacji
Jest także nazywany Opisem Technicznym Oprogramowania albo Mechanizmem Działania. Opis Techniczny Oprogramowania (nie mylić z opisem powykonawczym wdrożenia) to dokumentacja, pozwalająca osobie mającej odpowiednią wiedzę, samodzielnie zrozumieć jego działanie i wytworzyć go.
Poniżej tak zwany “opis minimalny i wystarczający opis produktu” (czyli także aplikacji). Wynalazek to produkt zgłaszany do patentowania, poza Urzędem Patentowym “opis wynalazku” to “opis przedmiotu zamówienia” kierowany do jego wykonawcy (przedmiot umowy na wykonanie):
Opis wynalazku powinien przedstawiać (ujawniać) wynalazek na tyle jasno i wyczerpująco, aby znawca Jest mógł ten wynalazek urzeczywistnić, a ekspert mógł dokonać rzeczowej analizy porównawczej z dotychczasowym stanem techniki. Za „znawcę z danej dziedziny” uważa się przeciętnego praktyka dysponującego przeciętną, ogólnie dostępną wiedzą z danej dziedziny w odpowiednim czasie, który dysponuje typowymi środkami i możliwościami prowadzenia prac i doświadczeń. Przyjmuje się, że specjalista taki ma dostęp do stanu techniki; tzn. informacji zawartych w podręcznikach, monografiach, książkach. Zna także informacje zawarte w opisach patentowych i publikacjach naukowych, jeżeli wynalazek dotyczy rozwiązań, które są na tyle nowe, że nie są zawarte w książkach. Ponadto, potrafi korzystać ze stanu techniki w działalności zawodowej do rozwiązywania problemów technicznych. Przedstawiony wynalazek powinien więc nadawać się do odtworzenia bez dodatkowej twórczości wynalazczej. Pod pojęciem tym należy rozumieć dodatkową działalność umysłową, eksperymentalną związaną z niepełną informacją techniczną zawartą w opisie wynalazku, a także konieczność dodatkowych uzupełniających badań naukowych, niezbędnych do realizacji rozwiązania według wynalazku w pełnym zakresie żądanej ochrony. Odtworzenie wynalazku powinno być możliwe na podstawie przeciętnej wiedzy specjalisty w danej dziedzinie, bez nadmiernego wysiłku. (art. 33 ust. 1 § 32 ust. 2 pkt. 63)
Projekt to Opis techniczny, i jako opis mechanizmu działania aplikacji zawiera:
- modele struktur dokumentów i komunikatów,
- metody wyliczania lub weryfikowania wartości wszystkich pół wyliczanych w tych dokumentach,
- model mechanizmu realizacji wymagań funkcjonalnych,
Rolą dewelopera jest dobór i uruchomienie środowiska oraz implementacja ww. mechanizmu w wybranym języku programowania. Więcej w opisie Projektowanie aplikacji.
Dokumentowanie istniejącego oprogramowania
Jeżeli celem jest opracowanie dokumentacji oprogramowania, które powstało ale nie ma ono profesjonalnej dokumentacji technicznej:
- dostaje aktualne dokumenty (jakiekolwiek jakimi dysponuje zleceniodawca)
- na bazie ich audytu powstaje dokumentacja techniczna w takiej postaci w jakiej jest możliwa do stworzenia na bazie dostarczonego materiału źródłowego,
Struktura i treść moich opracowań
Więcej na temat samego procesu powstawania tych produktów w: Analiza Potrzeb i Opracowanie Wymagań na Oprogramowanie, więcej o stosowanych metodach i standardach: Metoda analizy i projektowania systemów biznesowych. Słownik stosowanych metod i narzędzi jest dostępny na stronie: Słownik metodyczny.
Dodatek techniczny
Dlaczego moje projekty są zorientowane na dokumenty/komunikaty
Ważna uwaga! Dotyczy zarówno aplikacji tworzonych od zera jak i aplikacji już istniejących i rozwijanych. Ten opis dotyczy obu rodzajów aplikacji. Dokumenty w modelu logicznym mogą być utrwalane w bazie i modelu relacyjnym z pomocą dodatkowej warstwy ORM (mapowanie obiektowo-relacyjne), ma to jednak opisane niżej konsekwencje. Najczęściej stosowane przeze mnie wzorce projektowe to Repozytorium/Envelope, Active Record lub Active Table oraz DDD/Aggregate . Co do zasady na etapie analizy i projektowania nie tworzę i nie używam modeli danych rozumianych jako “jedna relacyjna baza danych dla projektu”.
Innymi słowy logika dziedzinowa to dokumenty jako komunikaty, a te mogą być i przesyłane i utrwalane. Jak widać po prawej, metody utrwalania są poza zakresem modelu dziedziny, czyli poza modelem opisującym mechanizm działania aplikacji.
