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 :
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 nie mikroserwisy) a nie od faktu poprzedzania implementacji projektowaniem.
