Cykl V ( " V model " lub " Vee model " w języku angielskim ) to model organizacji działań projektu charakteryzujący się zstępującym przepływem czynności uszczegóławiającym produkt aż do jego realizacji oraz rosnącym przepływem , która montuje produkt sprawdzając jego jakość. Ten model pochodzi z modelu kaskadowego, z którego wykorzystuje podejście fazy sekwencyjnej i liniowej.
Wzbogaca go jednak o działania integracyjne systemu z bardziej elementarnych komponentów i porównuje każdą kolejną fazę produkcji z odpowiadającą jej fazą walidacji, nadając jej w ten sposób kształt litery V.
Pochodzący ze świata przemysłowego cykl V stał się standardem w branży oprogramowania od lat 80 - tych . Od tego czasu, wraz z pojawieniem się inżynierii systemów , stała się ona standardem koncepcyjnym w wielu dziedzinach przemysłu.
Model ten stał się bardziej realistyczną alternatywą dla modelu kaskadowego, ze względu na rozważenie dodatkowych kroków podczas walidacji w celu rozróżnienia między testowaniem jednostkowym, testowaniem integracyjnym i testowaniem systemowym, co okazuje się bardziej odpowiednie dla złożonych systemów składających się z kilku komponentów.
W 1991 r. pod egidą NCOSE (które odtąd przekształciło się w INCOSE ), rząd USA opracował cykl V dla programu satelitarnego wymagającego złożonych systemów. Wybrany model wyróżnia system, który może składać się z kilku segmentów, które same składają się z elementów konfiguracyjnych, które mogą być sprzętowe, programowe lub organizacyjne. Elementy konfiguracyjne mogą same w sobie być zespołem składającym się z najbardziej podstawowych części. Model szczegółowo określa około pięćdziesięciu kroków (niektóre z nich przebiegają równoległymi ścieżkami). Od tego czasu model został przejęty przez niektóre federalne agencje stanowe, takie jak Departament Transportu i jest nadal używany.
W 1992 r. niezależnie, ale w tym samym czasie, władze niemieckie przyjęły cykl V, pod nazwą „ V-Modell ”, jako odniesienie dla rozwoju IT Ministerstwa Obrony. Od 1996 roku jego zastosowanie stało się regułą w projektach federalnych systemów informatycznych. Został on zastąpiony w 2005 roku przez „ V-Modell XT ”, zaprojektowany z myślą o większej elastyczności (przyrostek XT oznacza „ eXtreme Tailoring ”, czyli „ekstremalną elastyczność” w języku angielskim). Została wzbogacona o lepsze wsparcie integracji systemów i dodatkowo wspierana narzędziem informatycznym. Model ten obejmuje dziesięć etapów cyklu V, ale także dziesięć bardziej ogólnych czynności. Został zatem zaprojektowany jako zintegrowane ramy odniesienia dla zarządzania projektami i cyklu życia, z podziałem ról i obowiązków. Jest nadal w użyciu.
Wiele dziedzin przemysłu od tego czasu przyjęło cykl V w praktykach lub standardach przemysłowych, takich jak aeronautyka.
W uproszczeniu V-cykl obejmuje główne etapy, które w większości znajdujemy w modelu wodospadu :
Cykl V wnosi jednak dodatkowy wymiar, jakim jest system . Produkt projektu jest wówczas uważany za „system” złożony z kilku elementów, które są modułami lub komponentami. Wymaga to w przepływie odgórnym rozróżnienia ogólnego projektu systemu jako całości oraz szczegółowego projektu każdego komponentu. Implementacja jest następnie wykonywana komponent po komponencie. W przepływie w górę jest to ten sam sposób na wykonanie testów jednostkowych każdego komponentu, zintegrowanie systemu (czyli złożenie jego komponentów), a następnie wykonanie testu integracji.
Cykl V zwraca również większą uwagę na weryfikację i walidację. Testy jednostkowe i testy integracyjne weryfikują, czy komponenty i system działają zgodnie z projektem. Cykl V wzbogaca te kroki o test walidacji systemu, który nie tylko potwierdza, że system spełnia projekt, ale spełnia wymagania.
Poziom rozkładu nie jest ustalony. Niektóre modele cyklu V rozkładają systemy na podsystemy, zanim rozbiją je na komponenty. Dla każdego dodatkowego poziomu złożoności dodawany jest etap w V.
Przykładowe kroki to:
Jedna z różnic między recepturą fabryczną a recepturą ostateczną jest zasadniczo kontraktowa. Nierzadko zdarza się również, że klient deleguje walidację do organu walidacyjnego, który często składa się z ekspertów w celu zmniejszenia błędów walidacji.
Na poziomie zarządzania projektami różne etapy mogą prowadzić do powstania odrębnych faz na poziomej osi czasu. Kilka kolejnych kroków można jednak zgrupować w ramach większej fazy.
Cykl V definiuje etapy bez definiowania ról i obowiązków. Jednak niektóre zastosowania modelu definiują podział ról między organem decyzyjnym ( master developer ) a wykonawcą odpowiedzialnym za realizację projektu ( master at work ).
W kontekście projektów na dużą skalę pojawiły się role polegające na podziale i wyznaczaniu obowiązków:
| Poziom szczegółowości |
Role | Potrzeby i wykonalność |
Specyfikacja | Projekt architektoniczny |
Projekt szczegółowy |
Kodowanie | Testy jednostkowe |
Testy integracyjne |
Testy funkcjonalne | Testy akceptacyjne (akceptacyjne) |
|---|---|---|---|---|---|---|---|---|---|---|
| Funkcjonalny | MOA + AMOA | X | X | |||||||
| System | MOE + MOED | X | X | |||||||
| Technika i zawód |
Zespół Architektoniczny |
X | X | |||||||
| Składnik | Zespół z Rozwoju |
X | X | X |
Odnajdujemy w tym kroju literę V , stąd nazwa tego modelu.
Dla dobrej komunikacji między różnymi partnerami projektu konieczne jest stworzenie dokumentów referencyjnych.
| Potrzeby i wykonalność |
Specyfikacja | Projekt architektoniczny |
Projekt szczegółowy |
Kodowanie | Testy jednostkowe |
Testy integracyjne |
Testy funkcjonalne | Testy akceptacyjne (przepis) |
|---|---|---|---|---|---|---|---|---|
| Specyfikacja wymagań użytkownikaSpecyfikacje | Raport przepisu | |||||||
| Ogólne dane techniczneSpecyfikacja techniczna wymagań | Raport walidacyjny | |||||||
| Plik definicji oprogramowaniaPlik architektury technicznejPlan testów | Raport z testów integracyjnych | |||||||
| Szczegółowy raport projektowy | Raport z testów jednostkowych | |||||||
| Kod źródłowy |
Istnieje duże ryzyko uświadomienia sobie podczas wdrażania, że początkowe specyfikacje były niekompletne, błędne lub nieosiągalne. Istnieje również ryzyko pojawienia się nowych funkcjonalności wymaganych przez klientów (ryzyko odejścia od celów ), a także innych zagrożeń wymienionych w książce „ Mit człowieka-miesiąca ” . Głównie z tego powodu cykl V nie zawsze nadaje się do tworzenia oprogramowania . Jeśli do tego trybu zarządzania projektami nadają się projekty długoterminowe, często ryzykuje się, że nie będą już „trzymać się” zmieniających się w czasie potrzeb.
Inne modele umożliwiają łatwiejsze (czasem drastyczne) zmiany w początkowym projekcie po pierwszej implementacji lub serii wdrożeń. Zobacz np. na ten temat: Szybkie tworzenie aplikacji czy Agile metody zarządzania projektami. Z drugiej strony, metodom tym czasami brakuje identyfikowalności, co wymaga zaangażowania klienta zarówno pod względem projektowym, jak i prawnym: w cyklu V klient ma otrzymać to, co zamówił, podczas gdy metodami „zwinnymi”, klient staje się współdeweloperem, a zatem interweniuje na poziomie projektu. Ten niuans może mieć znaczenie w przypadku sporu między klientem a wykonawcą, w szczególności, gdy spór zostanie wniesiony do sądu.
Kompromisem jest zastosowanie jak najkrótszego cyklu V i rozwijanie projektu w postaci wersji, uwzględniając tym samym fakt, że projekt nie będzie doskonały i będzie ulepszany w stosunku do wersji. Umożliwia to również czerpanie korzyści z opinii z poprzednich wersji. Ten kompromis jest szczególnie pouczający w ramach projektu, dla zespołów z faz „upstream” poświęconych badaniu potrzeb, specyfikacji i projektowi („teoria”), które w ten sposób zostaną skonfrontowane z konkretnymi wynikami ( "wygodny"). Zauważ, że Microsoft praktykuje ten kompromis ze sztuką od kilkudziesięciu lat : opanuj identyfikowalność i czasy realizacji przy użyciu następujących po sobie cykli V tak krótkich, jak to możliwe, nawet jeśli oznacza to późniejszą dystrybucję aktualizacji… Na przykład wszystkie systemy operacyjne Microsoft od Windows 2000).
Cykl V wywodzi się z modelu kaskadowego i dziedziczy z niego defekty związane z podejściem fazy sekwencyjnej i liniowej. Tak więc cykl życia zależy od wymagań zidentyfikowanych na początku projektu, które mogą być niedostatecznej jakości lub niestabilne i mieć wpływ na jakość i koszty dalszych faz. Można go również skrytykować za sztywność spowodowaną rozdzieleniem faz według czynności: w dziedzinie oprogramowania trudno, jeśli nie niemożliwe, całkowicie oddzielić projektowanie projektu od jego realizacji.
Cykl V jest uznawany za rygorystyczne podejście do opracowywania produktów na podstawie wymagań. Ale jego sekwencyjny i liniowy pogląd jest redukcjonistyczny, ponieważ nie uwzględnia w wystarczającym stopniu współzależności między elementami systemu, w szczególności dla systemów wymagających silnej integracji. Niezbędne jest zatem zaradzenie tym ograniczeniom z jednej strony interdyscyplinarnym podejściem do architektury, az drugiej praktykami biznesowymi zapewniającymi spójność wymagań i projektowania na różnych etapach.
Co więcej, niektórzy autorzy zauważają, że w dziedzinie inżynierii systemów iteracje są regułą, a nie wyjątkiem. Sugerują, że planowanie powinno to uwzględniać, na przykład poprzez zapewnienie etapu prototypowania w celu walidacji zasad projektu (pomysł zaproponowany już przez Royce'a w 1970 r. dla podejścia kaskadowego). Analiza ta jest potwierdzona badaniami w dziedzinie inżynierii oprogramowania, które wykazują doskonałą wydajność w przypadku metod przyrostowych i iteracyjnych.
Ostatnie wydarzenia mają na celu zaradzenie tej krytyce poprzez:
Kolejna zmiana polega na interpretacji działań modelu V nie jako odrębnych, ściśle sekwencyjnych kroków, ale jako współzależnych procesów. Podejście to jest stosowane na przykład w normach IEC 62304 dotyczących oprogramowania dla urządzeń medycznych oraz IEC 82304-1 dotyczących ogólnych wymagań bezpieczeństwa oprogramowania zdrowotnego: są one często rozumiane jako narzucanie cyklu V, podczas gdy nakładają one tylko wymagania procesowe bez ustalania chronologii.
Wreszcie, niektórzy praktycy zalecają również łączenie cyklu V z praktykami zwinnymi (na przykład: wyrażanie wymagań w formie narracji użytkownika , programowanie w parach lub nawet przyjmowanie „ TDD ”, przy czym ta ostatnia praktyka może być postrzegana jako podejście programowanie zastępujące planowanie testów przewidziane w cyklu V).