Model V
Definiowanie cyklu tworzenia oprogramowania ma swoją długą tradycję. Jedną z pierwszych prób było stworzenie modelu wodospadowego (ang. waterfall). Choć bardzo prosty, w pełni oddawał istotę pierwszych projektów, w których budowano oprogramowanie. Jego jedyna wada to prostota nieuwzględniająca np. optymalności czasowej. Dokonano więc modyfikacji, zmieniając go w model, w którym dwie najważniejsze fazy: budowanie i weryfikacja, nie następują po sobie, ale wykonywane są równolegle. Oto 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ę budowania. Analizę modelu dokonamy na przykładzie wymyślonego programu „Przypominacz”. Jego podstawowym założeniem będzie, jak łatwo 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 późniejszych testów. Mając wiedzę, co chcemy osiągnąć, możemy określić, jak chcemy to sprawdzić i potwierdzić 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 i programistów 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ą projektanci niskopoziomowi, dzieląc wysokopoziomowy projekt na poszczególne komponenty (architektura komponentu). Tworzą  specyfikację, będącą informacjami wejściowymi dla programistów oraz testerów. Każdy komponent ma swoje interfejsy, które pozwolą mu współpracować z innymi elementami systemu. A 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 litery V. 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 modelu V

Model V precyzyjnie pokazuje zależności między kolejnymi etapami projektu. Każdy etap projektowania kończy się stworzeniem danych wejściowych dla następnej fazy oraz do korespondującej z nim fazy weryfikacji.

Model zachęca do jak najwcześniejszego rozpoczęcia procesu tworzenia planów testów, specyfikacji testowej i samego testowania, co z kolei może przełożyć się na wyższą jakość końcowego produktu.

Model V w. teraźniejszości

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, programistami, testerami i klientami. Jest wzorcem, o którym każdy człowiek chcący zajmować się oprogramowaniem, powinien przynajmniej wiedzieć.

 

[Aktualizacja] Artykuł powstał 19/05/2008 i został zaktualizowany.