Wprowadzenie
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:
O systemach projektowanych realnie komponentowo pisałem w artykule Interface-Oriented Design czyli architektura systemu zorientowana na interfejsy. Tu skupimy się na samym fakcie, że system jest komponentowy.
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.
Potencjalny konflikt interesu między projektantem (ustala zakres projektu) a przyszłymi użytkownikami (podwładni zamawiającego maksymalizujący ten zakres) rozwiązujemy “umocowując” projektanta “na poziomie” sponsora projektu.
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.
