Model V zwany sekwencyjnym

Modeli wytworzenia oprogramowania jest kilka. Dzisiaj zajmiemy się opisem modelu V inaczej nazywanym sekwencyjnym. Model V zawiera dwie podstawowe fazy pierwsza z nich to projektowanie, druga zaś to weryfikacja. Czynności wchodzące w skład tych faz odbywają się równolegle do siebie. Jest to niebywale istotne a zarazem w łatwy sposób tłumaczy skąd ta a nie inna nazwa modelu. Poniższy obrazek pozwoli wam zrozumieć model V i zapoznać się z czynnościami, które wchodzą w jego kształt.

Specyfikacja wymagań biznesowych a testy akceptacyjne

Określenie wymagań biznesowych z naszym klientem jest pierwszą czynnością którą musimy wykonać na tym etapie. Ustalamy tutaj między innymi co będzie wykonywał program który będziemy tworzyć. Jakie są oczekiwania klienta, jak wyobraża sobie jego działanie w momencie zakończenia implementacji wszystkich znajdujących się w nich funkcji. Ważne jest też określenie parametrów jakie mają w nim występować.  Testy akceptacyjne są bezpośrednio związane z fazą wymagań biznesowych. Wykonuje się za ich pomocą pierwszy i zarazem podstawowy test, w którym sprawdzamy czy program działa tak jak określiliśmy to w wymaganiach na samym początku.

Specyfikacja wymagań systemowych a testy systemowe 

W tej strefie niewątpliwie ważne jest określenie wymagań systemowych. Konieczne jest sprawdzenie tego czy to co zostało ustalone w poprzednim kroku jest możliwe do zrealizowania w rzeczywistości. Często można spotkać się z ustaleniami, które nie mają prawa bytu przez ograniczenia sprzętowe, systemowe bądź brak odpowiednich umiejętności np. programistów. Oczywiście ograniczenia są po to, aby je likwidować, brak umiejętności można szybko nadrobić wybierając programistów z odpowiednią wiedzą i to jest dosyć łatwe. Ograniczenia sprzętowe bądź systemowe nie są już tak rzeczywiste i ich zredukowanie czasami nie jest możliwe. Za pomocą testów systemowych sprawdzamy cały system, jego funkcjonalności. Testy te pozwolą nam określić zgodność z oprogramowaniem oraz sprzętem.

Architektura projektu a testy integracyjne 

Zespół projektowy na tym etapie zajmuje się zrozumieniem architektury projektu oraz jej projektowaniem. Zostają opracowane tutaj nie tylko metody oraz możliwości techniczne, ale również finansowe.  Po określeniu metod zostają one podzielone na mniejsze moduły w których sprawdzane są interakcje i transfery między nimi. Testy integracyjne są ściśle związane z architekturą projektu za ich pomocą bada się przekazywanie danych oraz transfer informacji między modułami.

Architektura komponentu a testy jednostkowe 

Architekci projektu po podzieleniu komponentu tworzą specyfikacje wraz z określeniem danych wejściowych dla testerów oraz programistów. Interfejsy występują w każdym projekcie i pozwalają na współpracę m.in z systemami operacyjnymi. Najlepszym nawykiem jest sprawdzenie osobno każdego komponentu czyli wykonania testów jednostkowych. Pozwoli to znaleźć błędy na wcześniejszym etapie, zanim wszystkie komponenty zostaną zespolone w całość i trudniej będzie znaleźć błędy.

Implementacja kodu 

Znajduję się na końcu fazy projektowania, po prawej stronie fazy weryfikacji. Tutaj zostaje rozwijany kod naszej aplikacji wraz z wszystkimi wcześniejszymi ustaleniami, które miały miejsce w fazie projektowania. Tworzony kod musi spełniać wszystkie standardy wraz z przestrzeganiem ustalonych wytycznych.

Zaletami modelu V są :

-> oszczędność czasu

-> prostota

-> wczesne wykrywanie błędów

-> wymagania są ustalone i zrozumiałe od początku procesu

-> pomaga określić zależności pomiędzy etapami projektu

W zależności od złożoności i wielkości projektu model te może być bardziej lub mniej złożony. Macie jakieś uwagi, przemyślenia? Chcecie podzielić się swoją wiedzą na ten temat? Czekam na wasze komentarze.