Proces weryfikacji i walidacji projektu

weryfikacja projektu

weryfikacja projektu to metoda weryfikacji projektu, która potwierdza, poprzez badanie i dostarczanie dowodów, że wynik zaprojektowanego produktu programowego spełnia jego specyfikacje wejściowe. Celem procesu weryfikacji projektu podczas tworzenia oprogramowania jest upewnienie się, że zaprojektowany produkt programowy jest taki sam, jak określono w specyfikacji.

Dane wejściowe projektu to wszelkie wymagania fizyczne i wydajnościowe, które stanowią podstawę projektu. Dane wyjściowe projektu to rezultat każdej fazy projektowania i całego nakładu pracy projektowej. W branżach regulowanych, takich jak produkcja wyrobów medycznych, ostateczny wynik projektu stanowi podstawę głównego rekordu urządzenia, dlatego terminologia dotycząca kontroli projektu tak często pojawia się w dokumentacji weryfikacyjnej.

W praktyce weryfikacja polega na porównaniu dwóch zestawów dokumentów: specyfikacji, norm i ograniczeń, które zostały dostarczone, z rysunkami, kodami i instrukcjami testowymi, które zostały wydane. Każda niezgodność między nimi stanowi wynik weryfikacji.

Walidacja projektu

Weryfikacja potwierdza spójność wewnętrzną. Walidacja stawia trudniejsze pytanie, czy specyfikacja w ogóle opisywała właściwy produkt.

Walidacja projektu Walidacja projektu to proces oceny produktu programowego pod kątem dokładnych wymagań użytkowników końcowych lub interesariuszy. Celem walidacji projektu jest przetestowanie produktu programowego po jego opracowaniu, aby potwierdzić, że spełnia on te wymagania, gdy jest używany w środowisku użytkownika.

Walidacja polega na wykazaniu spójności i kompletności projektu w odniesieniu do potrzeb użytkownika. Na tym etapie tworzy się wersję produktu i weryfikuje ją pod kątem wymagań użytkownika.

Poniższy baner opisuje dwie połowy aktywności w formie, w jakiej są one zazwyczaj przedstawiane w dokumentach projektowych.

Poniższy diagram przedstawia sam proces walidacji projektu, od potrzeb użytkowników po zatwierdzony produkt.

Celem jest udowodnienie za pomocą obiektywnych dowodów, że produkt spełnia udokumentowane potrzeby użytkownika. Dowód obiektywny to po prostu fizyczny dowód wyniku – obraz, plik tekstowy, plik audio lub podpisany raport – który potwierdza, że ​​procedura została faktycznie wykonana.

Dzięki tym obiektywnym dowodom proces ten konsekwentnie sprawdza, czy produkt spełnia określone wymagania. Obejmuje on działania testowe, inspekcję, analizę i podobne techniki, dlatego walidacja zazwyczaj opiera się na testowanie systemu oraz testy akceptacyjne użytkownika a nie na kontrolach na poziomie jednostek.

Różnica między weryfikacją projektu a walidacją

Zawsze pojawiają się nieporozumienia co do rozróżnienia weryfikacji i walidacji. To różne czynności, a obie są wykonywane na każdym etapie procesu rozwoju, a nie na jednym etapie.

Przydatny skrót: weryfikacja jest w większości praca statyczna w stosunku do dokumentów, podczas gdy walidacja jest głównie testy dynamiczne przeciwko działającej kompilacji.

Proces weryfikacji projektu

Proces weryfikacji składa się z pięciu etapów. W każdym z nich powstaje artefakt, od którego zależy kolejny etap.

Identyfikacja i przygotowanie:

• Podczas opracowywania specyfikacji, równolegle identyfikowane są działania weryfikacyjne. Pozwala to projektantowi upewnić się, że specyfikacja jest rzeczywiście weryfikowalna, a inżynier ds. testów może rozpocząć opracowywanie szczegółowych planów i procedur testowych. Wszelkie zmiany w specyfikacji muszą zostać zakomunikowane.
• Określ najlepsze podejście do przeprowadzenia weryfikacji i zdefiniuj metody pomiaru, wymagane zasoby, narzędzia i zaplecze.
• Ukończony plan weryfikacji jest omawiany z zespołem projektowym w celu wykrycia problemów przed sfinalizowaniem planu.

Planowanie:

• Planowanie weryfikacji jest czynnością równoległą, wykonywaną przez zespoły główne i deweloperskie. Odbywa się przez cały cykl życia projektu i jest aktualizowane za każdym razem, gdy zmieniają się dane wejściowe do projektu.
• W tej fazie dokumentuje się zakres testowanego oprogramowania lub systemu.
• Opracowuje się wstępny plan testów, który następnie jest udoskonalany. Plan uwzględnia kluczowe kamienie milowe, które zmniejszają ryzyko projektu.
• Wybierane są narzędzia, środowisko testowe i strategia rozwoju, a następnie określane są wymagania, które mają zostać potwierdzone poprzez inspekcję lub analizę.

Developing:

• Przypadek testowy rozwój pokrywa się z Metodologia SDLC Zespół projektowy wdrożył. Na tym etapie zidentyfikowano szereg metod testowania.
• Dane wejściowe projektu muszą zostać opracowane w taki sposób, aby nawet najprostsze działania weryfikacyjne były jednoznaczne i sprawdzalne.
• Czas weryfikacji ulega skróceniu, gdy podobne koncepcje są weryfikowane sekwencyjnie, ponieważ wynik jednego testu można ponownie wykorzystać jako dane wejściowe w kolejnym teście.
• TracPowiązania eability tworzone są pomiędzy przypadkami testowymi i odpowiadającymi im danymi wejściowymi projektu, aby zagwarantować, że każde wymaganie zostanie przetestowane i że dane wyjściowe projektu będą zgodne z danymi wejściowymi projektu.

Wykonanie:

• Procedury testowe opracowane w fazie rozwoju są wykonywane zgodnie z planem testów i ściśle przestrzegane w trakcie czynności weryfikacyjnych.
• Jeśli wystąpią nieprawidłowe wyniki lub jeśli jakakolwiek procedura będzie wymagała modyfikacji, zmiany muszą zostać udokumentowane i formalnie zatwierdzone.
• Każdy znaleziony problem jest rejestrowany jako defekt za pomocą standardowego proces zarządzania defektami.
• A tracmacierz możliwości służy do weryfikacji, czy każdy element projektu zidentyfikowany w planie testów weryfikacyjnych został przetestowany, a także do określenia współczynnika zdawalności.

Raporty:

• Czynność ta wykonywana jest na koniec każdego etapu realizacji weryfikacji.
• Raport z weryfikacji projektu zawiera szczegółowe podsumowanie wyników weryfikacji, obejmujące zarządzanie konfiguracją, wyniki dla każdego typu testów i problemy wykryte podczas czynności weryfikacyjnych.
• Weryfikacja projektu tracRaport o możliwościach tworzony jest na podstawie wymagań i odpowiadających im wyników testów, aby potwierdzić, że wszystkie wymagania zostały przetestowane i że zarejestrowano odpowiednie wyniki.
• Wszelkie niezgodności są dokumentowane i odpowiednio rozwiązywane.
• RevPrzeglądy przeprowadza się po zakończeniu weryfikacji projektu, a wyniki zostają formalnie zatwierdzone.

Proces walidacji projektu

Walidacja nie ma sztywnej sekwencji. Zamiast tego opiera się na niewielkim zestawie akceptowanych metod, a projekt zazwyczaj wykorzystuje więcej niż jedną z nich.

• Porównanie z podobnymi konstrukcjami. Niektóre projekty można zweryfikować, porównując je z podobnym sprzętem o podobnym przeznaczeniu. Jest to szczególnie istotne podczas weryfikacji zmian konfiguracji w istniejącej infrastrukturze lub standardowych projektów włączanych do nowego systemu lub aplikacji.
• Demonstracja i inspekcja. Do weryfikacji wymagań i innych funkcjonalności produktu można użyć jednego lub obu z nich.
• Analiza. Projekt można analizować za pomocą modelowania matematycznego lub symulacji odtwarzającej wymaganą funkcjonalność.
• Testowanie. Testy przeprowadza się na ostatecznym projekcie, aby sprawdzić, czy system jest w stanie działać zgodnie ze specyfikacją, czyli testy funkcjonalności oraz testy niefunkcjonalne spełniają wymagania użytkownika.
• Dokumentacja. Plan testów, ich wykonanie i wyniki powinny być dokumentowane i przechowywane w ramach dokumentacji projektowej. Walidacja to w ostatecznym rozrachunku zebrane wyniki wszystkich działań walidacyjnych.
• Uzasadnienie równoważności. Jeżeli w ostatecznej walidacji projektu stosowane są produkty równoważne, producent musi udokumentować podobieństwa i wszelkie różnice w stosunku do pierwotnej produkcji.

Przykład

Krótki przykład wyjaśniający to rozróżnienie.

• Weźmy na przykład prosty produkt: wodoodporny zegarek.
• W dokumencie dotyczącym wymagań produktu może być napisane, że „zegarek musi być wodoodporny podczas pływania”. To jest potrzeba użytkownika i to właśnie na jej podstawie przeprowadzana jest walidacja.
• Specyfikacja projektu może stanowić, że „zegarek powinien działać nawet podczas długotrwałego pływania”. To są założenia projektowe i to właśnie na ich podstawie przeprowadza się weryfikację.
• Wyniki testów powinny potwierdzić, że zegarek spełnia te wymagania. Jeśli nie, trwają prace nad nowymi wersjami, aż do momentu spełnienia tych wymagań.

Zwróć uwagę, jak zegarek może przejść weryfikację, a mimo to nie przejść walidacji. Jeśli specyfikacja definiuje długi czas pływania jako piętnaście minut, a prawdziwi pływacy pozostają w wodzie przez godzinę, wynik projektu idealnie odpowiada danym wejściowym i nadal nie zostanie zaliczony przez użytkownika.

Zalety walidacji i weryfikacji projektu

Korzyści opisane poniżej przynosi ciągłe prowadzenie obu tych czynności, a nie tylko ich końcowa realizacja.

• Projekty można monitorować w sposób ciągły, co pozwala na spełnienie wymagań użytkownika na każdym etapie.
• Walidacja projektu polega na zwróceniu uwagi na różnice między sposobem działania danej funkcjonalności a sposobem, w jaki ma ona działać.
• Udokumentowanie procedur walidacji ułatwia zrozumienie funkcjonalności w przypadku wprowadzenia zmian lub udoskonaleń.
• Czas rozwoju ulega stałemu skróceniu, a produktywność wzrasta, co pozwala na dostarczenie produktu zgodnie z oczekiwaniami.
• Proces ten definiuje zakres i zasięg każdej metody walidacji, która musi zostać zastosowana.
• Walidację można przeprowadzić, wykorzystując szczegółowe dane projektowe, które odzwierciedlają końcowe wymagania użytkownika.
• Wszelkie różnice między wynikiem a dokumentami potrzebnymi użytkownikowi są wychwytywane, a nie tracone.
• Zmiany w zatwierdzonym projekcie powodują ponowną czynność zatwierdzania, dzięki czemu rekord nigdy nie odbiega od produktu.
• Dokumentowanie każdej czynności wykonywanej w trakcie walidacji stanowi odpowiedni dowód na to, że projekt spełnia wymagania użytkownika.

Weryfikację i walidację projektu najlepiej zatem zaplanować w szerszym kontekście. cykl życia testowania oprogramowania i odwzorowane na drugim rodzaje testowania oprogramowania, a nie traktowane jako osobne ćwiczenie w zakresie zgodności.

FAQ