Inżynierowie systemów od dawna postrzegali V jako fundamentalną część dobrej inżynierii. Ostatnio jednak, V inżynierii systemów dostał zły rap. Nowa generacja inżynierów postrzega ją jako symbol powolnych, wodospadowych praktyk inżynierskich. Uważają te praktyki za nieistotne dla szybkości wymaganej przy tworzeniu oprogramowania.
Zwolennicy tradycyjnej inżynierii wolą V od metod „zwinnych”. Jest to szczególnie prawdziwe, gdy chodzi o krytyczne systemy.
Komu powinniśmy wierzyć?
Cóż, jeśli jesteśmy szczerzy, gdy V istnieje jako jedna chwalebna przepustka dla całego systemu, nowe pokolenie robi świetny punkt. V naprawdę może spowolnić rozwój dobrego oprogramowania.
W swoim rdzeniu, Inżynieria Systemów V jest logiczną konstrukcją. Opisuje odkrycie wymagań systemowych poprzez rozbicie systemu na mniejsze części, a następnie złożenie i walidację tych części.
Inżynierowie systemów stosują V w różnych kontekstach. Najczęściej V pojawia się w dużych organizacjach, takich jak Departament Obrony USA. Jest również popularny w instytucjach akademickich.
Te duże programy lub organizacje używają V jako części ich procesu wykonawczego najwyższego poziomu. Ogólny przepływ pracy składa się z siedmiu faz:
Proces rozpoczyna się po lewej stronie V, gdzie (1) generowane są koncepcje. Następnie, (2) wymagania dla całego systemu są definiowane, dekomponowane i alokowane. Następnie, (3) komponenty systemu są szczegółowo projektowane.
Implementacja występuje na dole V (4). W tym miejscu projektowane komponenty są tworzone zgodnie z wymaganiami z wcześniejszego etapu procesu.
Przesuwając się w górę prawej strony litery V, komponenty te są (5) integrowane razem w końcowy system. Zintegrowany system jest następnie weryfikowany, aby zapewnić, że spełnia oryginalne wymagania i walidowany, aby zapewnić, że spełnia potrzeby użytkownika (6). Wreszcie, (7) system jest dostarczany i utrzymywany.
Wyzwania V
Wykonywanie procesu V okazuje się kłopotliwe dla wielu dużych projektów – zwłaszcza tych, które zawierają oprogramowanie.
Integracja
Jednym z głównych problemów jest to, że integracja występuje zbyt późno w procesie rozwoju. Programy polegające na V czekają, aż komponenty oprogramowania będą kompletne, aby ograniczyć kosztowne ponowne prace integracyjne.
Ręczna integracja komponentów oprogramowania zajmuje ogromną ilość czasu. Rzeczywistość, o której wszyscy wiemy, że jest prawdziwa, jest taka, że oprogramowanie nigdy nie jest skończone. Czynności integracyjne pozostawione na koniec są wykonywane w pośpiechu, aby sprostać harmonogramowi programu.
W V, zintegrowane komponenty zazwyczaj spełniają wymagania funkcjonalne, ale często nie są bezpieczne, pewne lub poprawne.
Weryfikacja &Walidacja
Czekanie, aż system zostanie całkowicie zintegrowany, aby przeprowadzić weryfikację i walidację (V&V) potęguje ten problem. Wdrażanie poprawek powoduje falowanie w całym systemie, co sprawia, że rozwiązywanie problemów, które pojawiają się podczas V&V, jest trudne i kosztowne.
Programy często wprowadzają poprawki „na poziomie systemu” zamiast rozwiązywać źródło problemu – jest to podejście typu „band-aid”. Ryzyko związane z oprogramowaniem jest często ograniczane przez praktyki takie jak zapory na poziomie systemu i oprogramowanie antywirusowe, zamiast rozwiązywania go w kodzie.
Poprawki zmniejszają szansę, że użytkownicy napotkają wadę, ale sama wada nie jest naprawiona i nadal czai się w systemie.
Podjęcie wyzwania
Koncepcje zawarte w V Inżynierii Systemów nie stanowią problemu – problemem jest struktura V, która nie ma zastosowania do oprogramowania
Nowoczesne techniki mogą umożliwić ciągłą integrację oprogramowania, nawet w przypadku dużych programów. Używanie narzędzi i procesów, które obejmują wczesną integrację i weryfikację, nie neguje podstawowych koncepcji V – one wzmacniają V tak, że działa dla rozwoju oprogramowania.
Wynikiem końcowym jest oprogramowanie, które jest poprawne przy tworzeniu, oraz system, który jest tańszy, bezpieczniejszy i szybszy do dostarczenia.
.