Strona poświęcona mojej pracy naukowej i usługom jakie świadczę polskim podmiotom. Zapraszam tych którzy szukają wiedzy i tych którzy szukają wsparcia w swoich projektach informatyzacji.
"Jeżeli nie potrafisz czegoś narysować, to znaczy że nadal tego nie rozumiesz…"
Zarządzanie ryzykiem to proza życia kierowników projektów. Z jednej strony doświadczony kierownik projektu powinien doskonale radzić sobie z ryzykiem, z drugiej zaś strony praktyka projektów pokazuje, że efekty są niestety słabe bo ok. 90% IT na świecie ma przekrocozne budżety i terminy .
Jednym z ciekawszych narzędzi zarządzania ryzykiem jest mało popularny tak zwany stożek niepewności. Ogólna zasada planowania mówi, że im bardziej w przyszłość wybiegają prognozy tym bardziej są one niepewne. Jest nie tylko intuicyjne ale i udowodnione matematycznie. Stożek niepewności to wykres pokazujący związek pomiędzy kosztami projektu a posiadaną wiedzą na etapie inicjacji projektu np. implementacji (dostarczenia) oprogramowania. Poniżej jeden z przykładów jego zobrazowania:
Stożek niepewności
Stożek ten (stożek niepewności) to narzędzie empiryczne (!), obrazuje spodziewane konsekwencje jakimi są koszty, generowane przez niepewność (przedwczesne, nieudane prototypy, wprowadzanie zmian po przedwczesnym rozpoczęciu prac implementacyjnych i wdrożeniowych, itp.).
Na powyższym wykresie, czerwona linia obrazuje koszty etapu prac bez analiz i projektowania (agile) a zielona koszty prac poprzedzonych analizami i projektowaniem. Linie te spotykają w punkcie, w którym wiedza o ostatecznej wersji produktu jest już taka sama. Punkty oznaczone “diamentem” to kamienie milowe projektu. Wartość kosztu odniesienia 1.0 to sytuacja, w której w momencie rozpoczęcia projektu nie byłoby żadnych niewiadomych (ryzyko zakresu projektu = zero). Całkowity koszt projektu to pola pod krzywymi (pomiędzy daną krzywą a poziomem zero lewej osi). Praktyka pokazuje więc, że brak planowania i projektowania podnosi koszty projektu średnio czterokrotnie.
W przypadku aplikacji będącej monolitem wykres reprezentuje cały projekt (“water fall”, metoda wodospadowa), czyli projekt trwający nie raz kilka lat. Prawdopodobieństwo, że realizacja detalicznie zaplanowanego np. na 5 lat projektu będzie wymagała korekty planów lub wprowadzania zmian do projektu, graniczy obecnie z pewnością:
W przypadku zastosowania metod obiektowych, zorientowanych na komponenty/mikroserwisy, wykres Stożek niepewności reprezentuje dostarczenie jednej usługi aplikacyjnej (przypadek użycia, implementowanej jako komponent, patrz także iteracyjno-przyrostowe dostarczanie oprogramowania jako kolejnych usług aplikacyjnych, MVP: Minimum Value Product). Implementacja jednej takiej usługi z reguły mieści się w jednym kwartale. W efekcie praktycznie eliminujemy skutki niepewności, planując realizację projektu tak, by żadne plany nie wybiegały zbyt daleko w przyszłość (z reguły granica jest rok budżetowy). Jest to możliwe dzięki odejściu od monolitycznej architektury aplikacji. Realizacja projektu wytwarzania aplikacji o komponentowej (np. mikroserwisy) architekturze wygląda jak poniżej:
Warto tu zwrócić uwagę, że aplikacje zbudowane w oparciu o jedną i centralną bazę danych w modelu relacyjnym (RDBMS) są właśnie typowymi monolitami, np. większość powszechnie znanych dużych systemów ERP. Duże systemy relacyjnych baz danych są z tego powodu od dawna krytykowane:
W tym przypadku oferty (obietnice) dostawców tego typu systemów (monolity) to zielona linia na diagramie Stożek niepewności, a faktyczne koszty tych wdrożeń, polegające na bieżącej, prowadzonej ad-hoc adaptacji, to linia czerwona, co potwierdzają statystyki .
Little, T. (2006). Schedule estimation and uncertainty surrounding the cone of uncertainty. Software, IEEE, 23, 48–54. https://doi.org/10.1109/MS.2006.82
Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).
