Moją rolą w projekcie jest analiza spisanych przez klienta (analityków biznesowych) potrzeb i opracowanie modelu mechanizmu ich realizacji (application design). Adresatem moich produktów jest Developer. Prowadzę także nadzór autorski wspierając prace dostawcy opisanego rozwiązania. Często pomaga model procesów biznesowych, który także pomagam opracować na bazie dostarczonych mi materiałów.
Zgodnie z zasadą 1:10:100 wykrycie błędu na etapie projektowania kosztuje 1 dolara, podczas gdy jego wykrycie podczas standardowych testów kosztuje 10 dolarów, a po wdrożeniu – 100 dolarów (Ensure success in modernization projects with external IV&V services).
Brak specyfikacji kosztował wykonawcę cały kontrakt [wyrok SA we Wrocławiu, I ACa 796/13]. Analiza przedwdrożeniowa i specyfikacja oprogramowania to dwa zupełnie różne dokumenty. Analiza mówi CO chcemy osiągnąć. Specyfikacja mówi JAK to dokładnie ma działać. Mylenie ich lub pomijanie specyfikacji kosztowało wykonawcę w tej sprawie cały kontrakt i przegraną w sądzie. Wykonawca, co istotne, przygotował specyfikację funkcjonalną, ale nie zadbał o osobną specyfikację techniczną dla jednego z kluczowych modułów systemu. Efekt? W trakcie realizacji umowy nie dało się ustalić, do czego dokładnie wykonawca się zobowiązał. System nie działał jako całość: moduły nie wymieniały danych poprawnie, a oprogramowanie nie nadawało się do użytku biznesowego. Zamawiający odstąpił od umowy.
Sąd wprost wskazał: firma IT, która podejmuje się wykonania zaawansowanego systemu bez dokładnej specyfikacji jego istotnych elementów, nie może skutecznie twierdzić w sądzie, że odpowiedzialność za niepowodzenie leży wyłącznie po stronie zamawiającego.
➡ Jeśli jesteś zamawiającym: nie wystarczy dobra analiza biznesowa. Zadbaj o to, żeby przed podpisaniem umowy każdy moduł systemu miał swoją szczegółową specyfikację – najlepiej jako załącznik do umowy.
➡ Jeśli jesteś wykonawcą: nie zaczynaj kodowania, dopóki nie masz specyfikacji każdego istotnego elementu systemu. Bez niej nie tylko ryzykujesz projekt – znacznie pogarszasz też swoją pozycję procesową w razie sporu. Możesz próbować twierdzić i wykazywać różnymi dowodami, że zamawiający zmieniał założenia, ale bez specyfikacji będzie to bardzo trudne. (źr.: Tomasz Sowa, LL.M. partner at Sowa i Partnerzy – Adwokaci i Radcowie Prawni)
Czy wdrożenia ze wsparciem architekta-projektanta znacznie rzadziej ponoszą porażki?
Tak, wdrożenia systemów IT z 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 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”: Architekt stanowi bufor między biznesową wizją klienta a technologicznymi możliwościami wykonawcy, 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.
Zapobieganie „Scope Creep”: 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.
.
Co robi Analityk-projektant?
Specjalizuje się w analiza, projektowaniu i specyfikowaniu oprogramowania klasyfikowanego jak Enterprise Systems:
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.
