Model V

Definiowanie cyklu tworzenia oprogramowania ma już swoją długą tradycję. Jedną z pierwszych prób było stworzenie modelu wodospadu (ang. waterfall). Choć bardzo prosty, w pełni oddawał on pierwsze projekty, w których budowano oprogramowanie. Jego jedyna wada to prostota nieuwzględniająca np. optymalności czasowej. Dokonano więc jego modyfikacji, zmieniając go w model, gdzie dwie najważniejsze fazy: projektowanie i weryfikacja, nie następują po sobie, ale wykonywane są równolegle - model V.

 

Jak powstaje oprogramowanie według V?

Poniższy obrazek przedstawia Model V i tłumaczy też jego nazwę.

 

Wytwarzanie oprogramowania w modelu V

 

 

Pierwszym stadium tworzenia oprogramowania jest Idea. Kiedy podejmiemy decyzję, że koncepcja znajdzie swoją realizację "wchodzimy" w Model V i fazę projektową. Analizę modelu dokonamy na przykładzie programu „Przypominacz”. Jego podstawowym założeniem będzie, jak nie trudno się domyślić, przypominanie o wydarzeniach. Musimy zacząć od wymagań: O czym ma nam przypominać? Jak ma przypominać? Jakie parametry można w nim nastawić? Itd. Stworzone wymagania są podstawą do rozpoczęcia definiowania weryfikacji. Mając wiedzę, co chcemy osiągnąć, możemy określić, jak chcemy to sprawdzić i czy będzie to działać. Pierwszy i podstawowy test końcowy to, jeśli program się uruchomi, czy przypominacz przypomina?!

Wymagania podlegają analizie, podczas której zespoły architektów, programistów, testerów itp., decydują czy dana Idea jest realizowalna. Czy da się zaimplementować wszystkie wstępne założenia? Ważne jest, choć niestety rzadko stosowane, by w procesie analizy uczestniczyli testerzy, którzy na poziomie weryfikacji mogliby zacząć tworzyć podwaliny testowania systemowego.

Następnie do gry wchodzą architekci projektu dzieląc go na poszczególne komponenty (architektura komponentu). Tworzą oni specyfikację, będącą informacjami wejściowymi dla programistów oraz testerów. Każdy projekt ma swoje interfejsy, które pozwolą mu na przykład współpracować z systemem operacyjnym. Z kolei każdy komponent może być poddany osobnemu sprawdzeniu zanim zostanie zintegrowany w całość. Tu pojawiają się pojęcia testowania interfejsów i komponentów. Implementacja jest teoretycznym końcem lewego ramienia. Prawe ramię, czyli weryfikacja ,to najprościej rzecz ujmując, sprawdzanie, czy założenia wstępne zostały wypełnione; poczynając od sprawdzania najmniejszych komponentów na całym zintegrowanym systemie kończąc. Testy końcowe to zazwyczaj tzw. testy akceptacyjne, odpowiadające na pytanie, czy dany produkt spełnia wymagania klienta. W naszym przypadku byłoby to sprawdzenie, czy przypominacz zachowuje się tak, jak zakładaliśmy to sobie na początku.

 

Zalety

Model V precyzyjnie pokazuje zależności, jakie powinny łączyć kolejne etapy projektu. Każdy etap projektowania kończy się stworzeniem danych wejściowych dla następnej fazy oraz do korespondującej z nim fazy weryfikacji.

Zachęca do jak najwcześniejszego rozpoczęcia procesu tworzenia planów testów, specyfikacji testowej i samego testowania.

Dzięki analizie grafu możemy łatwo zidentyfikować obszary, gdzie stworzona dokumentacja powinna być sprawdzona.

 

Model V a teraźniejszość

Model V ciągle jest jednym z najważniejszych modeli tworzenia oprogramowania. Choć mało szczegółowy i mało wydajny, daje przykład idealnego świata kooperacji między architektami, a programistami, testerami i klientami. Jest niedoścignionym wzorcem, o którym każdy człowiek chcący zajmować się oprogramowaniem, powinien przynajmniej wiedzieć.

Jego najnowszą wersję V model XT można znaleźć, niestety tylko po niemiecku, na stronie: http://www.v-modell-xt.de/

 

 

 

Najbliższe terminy szkoleń

Partnerzy

Narzędzia testerskie