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 tego nie rozumiesz…"
Ten artykuł to krótki wpis o tak zwanym V‑modelu. Jest to model wytwarzania oparty na pętli analizy, projektowania, testowania i przekazania do użytku. Oparty jest połączeniu dwóch cykli życia: projektowania i wytwarzania. jest stosowany w szeroko pojętej inżynierii systemów, nie koniecznie oprogramowania.
W branży IT znana jego postać wygląda np. tak:
Niedawno w innej wersji v‑model publikowałem, pisząc o tym czym jest mechatronika :
Czy V‑model to waterfall
Bardzo często autorzy piszą, że jest to skompromitowany, tak zwany wodospadowy (waterfall), system wytwarzania oprogramowania. Była by to prawda, gdy zawsze chodziło o hipotetyczny „cały system”. Jednak V‑model, jako metoda, nie precyzuje skali projektu. W przypadku większości dawnych konstrukcji mechanicznych była by to prawda, jednak modułowość to od lat cecha każdej konstrukcji inżynierskiej. Model ten więc nie koniecznie musi być tym „złym wodospadem”. Pojawiają się od czasu do porównania między wodospadem, v‑modelem a agile, jako metodami, jednak ich autorzy nie precyzują tego, czy w danym przypadku chodzi o moduł czy o cały system . Model ten jest stale przedmiotem poszukiwań poprawy jakości i większej „zwinności” .
Myślę, że klasyczny wodospad, jako metoda prowadzenia powoli odchodzi w niepamięć (powinien). Nie zapominajmy jednak, że rozpoczynanie tworzenia oprogramowania od projektowania wspólnego (relacyjnego) modelu danych to taki właśnie klasyczny strukturalny wodospad. Więc jak?
Modułowe systemy to w zasadzie zagnieżdżone dwa v‑modele. Najpierw projektujemy architekturę całości: powstaje model komponentowy. Kolejne etapy to iteracyjne dostarczanie poszczególnych komponentów. W konstrukcjach elektromechanicznych i tak musimy czekać na ukończenie całości (samochód czy pralka albo jest w całości, albo nie mamy czego używać). W przypadku oprogramowania możemy skupić sie na pojedynczych komponentach.
Poprawnie zaprojektowane oprogramowanie to samodzielne usługi aplikacyjne. Złożone nie raz, aplikacje powstają jako zbiory takich usług, na rynku widzimy je jako gotowe wielomodułowe systemy. Jednak dedykowane projekty nie mają rygoru „oddania w całości”. Usługi aplikacyjne mogą być oddawane jedna po drugiej. Wtedy opisywany tu v‑model to najpierw lewa strona: tak zwana „architektura wysokiego poziomu”, a następnie iteracyjno-przyrostowe realizacje kolejnych komponentów i usług. Każda kolejna usługa (komponent) to projektowanie, implementacja, testy i oddanie do użytku.
Podejścia znane jako Use Case 2.0 czy Microservice, to właśnie takie modułowe
Jednak nadal na etapie analiz i projektowania autorzy tych projektów bardzo często nadal poprzestają na opisu idei, czyli procesu biznesowego i nazwanych usług, nie jest to jednak projektowanie systemu a co najwyżej biznesowe wymagania . V‑model opiera się na tym, że implementacja jest poprzedzana projektowaniem, czyli swoistym studium wykonalności. Jest to sprawdzona metoda z każdej innej inżynierii:
zanim zaczniesz budować, upewnij się, że wiesz co powinno powstać.
Tak więc v‑model wygląda na dobrą metodę-proces. To czy jest to wodospad czy nie, zależy od architektury całości (monolit czy komponenty) a nie od faktu poprzedzania implementacji projektowaniem.
Poniżej schemat obrazujący V‑model z perspektywy dzisiejszych systemów mechatronicznych:
Godna podkreślenia jest tu granica między architekturą a implementacja oraz fakt, że architektura to komponenty multidiscyplinarne: komponent systemu może być konstrukcją mechaniczną, elektromechaniczną, itp.. może być komputerem. Tu ważna uwaga: powszechnie mówi sie o oprogramowaniu jako komponencie, jednak jest to pewne uproszczenie, gdyż komponentem systemów są komputery a nie „oprogramowanie”. Elementem sterującym w samochodzie czy pralce jest umieszczony w nich i zintegrowany z resztą komputer, a nie „oprogramowanie”.
Skoro system z zasady jest tworem składającym się elementów to znaczy, że także z zasady ma wewnętrzna architekturę. Rakieta, samochód czy pralka to systemy, jest jednak istotna różnica między systemem jakim jest np. samochód a systemem jakim jest grupa ludzi, umeblowanie mieszkania czy aplikacja jak element komputera. Samochód albo jest kompletny albo nie jest działającym samochodem. Jednak każdy element systemu umeblowania mieszkania sam z siebie posiada określoną i niezależną od pozostałych elementów tego systemu funkcjonalność: każdy mebel do czegoś służy. Można nie mieć w pełni umeblowanego salonu mając już jednak jeden fotel i siedzieć w nim by odpocząć.
Identyczną sytuację mamy w przypadku złożonego oprogramowania, jednak pod warunkiem, że nie jest ono (jego architektura) monolitem. Jeżeli ma architekturę prawdziwie komponentową (komponent są od siebie realnie niezależne), budowa takiego systemu to dwupoziomowy V‑model jaki pokazano poniżej:
Mając projekt HLD systemu mamy zdefiniowane jego komponenty a konkretnie ich interfejsy i wymaganą logikę działania (funkcję jaką pełnią w systemie). W efekcie każdy komponent, na swoim poziomie, ma wymagania (zdefiniowane interfejsy) i powstaje także w procesie V‑model. Z uwagi na wyżej opisaną specyfikę systemów jaką jest oprogramowanie, często komponenty pojedynczo posiadają przydatną użytkownikowi aplikacji funkcjonalność. To oznacza, że można je dostarczać niezależnie i w ustalonej kolejności. Tak właśnie, iteracyjnie-przyrostowo, powstaje złożone oprogramowanie podzielone na niezależne komponenty .
Konflikt interesu czyli role w projekcie
Pierwszy cytowany diagram w tym tekście pokazuje V‑model jako model pracy developera. Jednak w zarządzaniu projektami inżynierskimi coraz częściej podkreśla się kwestie jakości, a tam gdzie pojawia się pojęcie jakości i nadzoru pojawia sie pojęcie konfliktu interesu.
Czym jest konflikt interesu? Jest „starym jak świat problemem”:
Nemoiudexincausasua– nikt nie może być sędzią we własnej sprawie. Nullus idoneus testis in re sua intellegitur – nikt nie może być wiarygodnym świadkiem we własnej sprawie.
starorzymskie paremie prawnicze
Dlatego diagram ten uzupełniłem pokazując trzy kluczowe role w projekcie inżynierskim:
Główny konflikt interesu to zamawiający vs. wykonawca – klasyczna sprzeczność ceny i jakość oraz zakresu: zamawiającemu zależy na maksymalizacji funkcjonalności a wykonawcy na: minimalizacji kosztów (projekt fixed-price) lub maksymalizacji kosztów (projekt T&M).
Dlatego po stronie zamawiającego angażujemy projektanta bo:
zamawiający nie ma tej kompetencji,
odbieramy te role wykonawcy z powodu ww. konfliktu interesu.
Praktyka pokazuje, że brak separacji ww. ról jest jedną z głównych przyczyn niepowodzeń projektów w branży IT:
ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy systemów mogą być cennym elementem cyfrowej transformacji, ale nigdy nie powinni mieć całkowitej, niekontrolowanej władzy nad całym przedsięwzięciem (źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : THE HERTZ VS. ACCENTURE DISASTER)
Podsumowanie
Jak pokazano można projektować, nawet bardzo duże, systemy informatyczne nie robiąc tego metodą mityczne wodospadu (waterfall). Waterfall to metoda (model) wytwarzania oprogramowania „w jednym przebiegu”, czyli przy założeniu, że prace implementacyjne rozpoczynają się dopiero po opracowaniu ostatecznej specyfikacji systemu. Taki model wytwarzania jest cechą systemów o monolitycznej architekturze. Tu warto podkreślić, że monolitem jest także modułowy systemy zbudowany na jednej, centralnej bazie danych w modelu relacyjnym.
Podział systemu na komponenty w pierwszym etapie analizy i projektowania (architektura wysokiego poziomu) to dekompozycja problemu i opracowanie rozwiązania problemu. Kolejne prace to „raz z razem”, projektowanie detali kolejnego określonego komponentu (architektura niskiego poziomu), jego integracja z już istniejącymi, i wdrażanie. Tak powstają bardzo sprawnie, iteracyjnie przyrostowo, nawet bardzo duże systemy i nie ma to nic wspólnego z metodą zwana „waterfall” .
Podkreślić tu należy, że kluczowe dla procesu V‑model, jest to, że z zasady implementacja poprzedzana jest projektowaniem. Jest to ogromna zaleta tej metody, gdyż na dowolnym etapie mamy dokumentacje opisująca działanie systemu. Ta (ta sama) dokumentacja jest wymaganiem na początku i opisem technicznych na końcu.
Jednym z największych problemów w branży informatycznej jest nieaktualna dokumentacja oprogramowania lub jej brak (patrz artykuł Dług informacyjny). V‑model to proces usuwający te wadę. Po drugie prace koncepcyjno-projektowe na modelach (a nie na kodzie) są znacznie efektywniejsze i tańsze. Praktyka tworzenia dokumentacji dopiero po oddaniu oprogramowania do użytku, jest bardzo kosztowna i nieefektywna, oraz obarczona dużym ryzykiem, pominięć.
Kluczem zaś jest separowanie ról z konfliktem interesu.
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).
Aby zapewnić jak najlepsze wrażenia, korzystamy z technologii, takich jak pliki cookie, do przechowywania i/lub uzyskiwania dostępu do informacji o urządzeniu. Zgoda na te technologie pozwoli nam przetwarzać dane, takie jak zachowanie podczas przeglądania lub unikalne identyfikatory na tej stronie. Brak wyrażenia zgody lub wycofanie zgody może niekorzystnie wpłynąć na niektóre cechy i funkcje.
Funkcjonalne
Zawsze aktywne
Przechowywanie lub dostęp do danych technicznych jest ściśle konieczny do uzasadnionego celu umożliwienia korzystania z konkretnej usługi wyraźnie żądanej przez subskrybenta lub użytkownika, lub wyłącznie w celu przeprowadzenia transmisji komunikatu przez sieć łączności elektronicznej.
Preferencje
Przechowywanie lub dostęp techniczny jest niezbędny do uzasadnionego celu przechowywania preferencji, o które nie prosi subskrybent lub użytkownik.
Statystyka
Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do celów statystycznych.Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do anonimowych celów statystycznych. Bez wezwania do sądu, dobrowolnego podporządkowania się dostawcy usług internetowych lub dodatkowych zapisów od strony trzeciej, informacje przechowywane lub pobierane wyłącznie w tym celu zwykle nie mogą być wykorzystywane do identyfikacji użytkownika.
Marketing
Przechowywanie lub dostęp techniczny jest wymagany do tworzenia profili użytkowników w celu wysyłania reklam lub śledzenia użytkownika na stronie internetowej lub na kilku stronach internetowych w podobnych celach marketingowych.
Widzę, że zainteresował Cię ten artykuł, cieszę się. Czy udało Ci się znaleźć to czego szukasz? Jeżeli nie, i nadal szukasz pomocy kliknij: OFERTA DLA FIRM. Jeżeli chcesz się uczyć, kliknij tu: SZKOLENIA i KONSULTACJE. Czy uważasz, że pisanie tego bloga jest ważne? Wesprzyj tę pracę WPŁAĆ DAROWIZNĘ
Najczęściej kupowana usługa to audyt i recenzja dokumentacji projektowej (np. Twojego dostawcy) to koszt 470 GBP, więcej na stronie OFERTA.
Modele procesów biznesowych Twojej firmy? Wymagania na oprogramowanie? Robię to skutecznie od 20 lat. Więcej na stronie : OFERTA.
Szukasz bieżącego merytorycznego wsparcia a nie masz czasu na szkolenia bo projekty w toku? Oferuję stałe ryczałtowe wsparcie, więcej na stronie : OFERTA.