Podpisanie weryfikacji poza zakresem

Powszechnym podejściem projektowym do zatwierdzania weryfikacji jest rozpoczęcie od kompleksowego planu weryfikacji, obejmującego wszystkie wymagania określone w specyfikacjach i przypadkach użycia, definicję architektury i wszelkie inne odpowiednie dokumenty. Następnie opracowywane są testy obejmujące każdy element planu weryfikacji. Testy te są uruchamiane i debugowane, a zidentyfikowane problemy są rozwiązywane w ramach projektu. Ten proces powtarza się aż do osiągnięcia uzgodnionego poziomu pokrycia. Pokrycie funkcjonalne jest miarą tego procesu i dobrze sprawdza się w jego zakresie. Główni dostawcy automatyzacji projektowania elektronicznego (EDA) mają narzędzia do przeprowadzania symulacji, gromadzenia statystyk pokrycia i pomocy w dalszym ulepszaniu tych wskaźników. Ale to nie cała historia w Signoff. Pokrycie mierzy zgodność z planem weryfikacji, który jest oddalony o kilka kroków od wymagań klienta. Skąd projektanci wiedzą, że krytyczne informacje nie zostały pominięte lub dodane po drodze?

Co jeszcze ma znaczenie w podpisie?

Liczy się wszystko przed wewnętrznie opracowanymi specyfikacjami/wymaganiami funkcjonalnymi. Nie jest możliwe całkowite zamknięcie pętli między wymaganiami klienta a wdrożeniem/weryfikacją, chyba że zostaną one uwzględnione w analizie. Teraz łańcuchy wartości są skompresowane, a systemy na chipie (SoC) stają się coraz bardziej specyficzne dla aplikacji. Klienci oczekują projektów dostosowanych dokładnie do ich potrzeb, więc to, co zdefiniowali jako wymagania, musi zostać dopasowane we wdrożeniu/weryfikacji. Nie zostanie to dobrze przyjęte, jeśli klient odkryje, że oczekuje się od niego łatania niezgodności.

Wyzwanie polega na tym, że definicja może być dość mieszanym zestawem danych wejściowych: Word, PDF, dokumenty oparte na DITA, arkusze kalkulacyjne, Simulink, SysML lub prototypy modeli wirtualnych oraz oprogramowanie, które powinno działać na ostatecznym sprzęcie (być może z uwzględnieniem niektórych zmiany). Mogą również istnieć udokumentowane wymagania w formacie DOORS, Jama Connect lub podobnym. W jaki sposób zespół weryfikacyjny, zespół projektowy lub architekt potwierdza, że ​​wdrożenie i weryfikacja są zgodne z wymaganiami? Oczywiście zrobią wszystko, co w ich mocy, ale gdzie jest szczegółowy i podlegający audytowi proces, który zapewnia, że ​​każde wymaganie jest odwzorowywane na realizację wdrożenia i że weryfikacja wdrożenia jest odpowiednio uwzględniona?

Aby uczynić to bardziej konkretnym, załóżmy, że istnieje funkcja, której chce jeden ważny klient, ale nikt inny jej nie potrzebuje. Być może przez przeoczenie lub nieporozumienie ta funkcja nie znalazła się w specyfikacji/wymaganiu funkcjonalnym. To zdarza się zbyt często. Nawet ideał 100% pokrycia nie rozwiąże tego problemu, ponieważ pokrycie jest tak dobre, jak plan weryfikacji. Istnieje duży problem, jeśli plan weryfikacji nie odzwierciedla dokładnie wymagań.

Albo załóżmy, że podczas projektowania zespół decyduje, że nie może wdrożyć dokładnie tego, o co prosi specyfikacja, ale wdraża alternatywę z przekonaniem, że będzie ona równie dobra, a nawet lepsza. Zespół nie zdaje sobie sprawy, że ta zmiana wpłynie na wydajność w niektórych rzadkich, ale ważnych przypadkach użycia. Może uda się to uchwycić w symulacji? Być może, ale bardzo trudno jest być wszechstronnym w testowaniu na poziomie systemu. Istnieje realne ryzyko, że ta problematyczna zmiana przetrwa aż do krzemu.

Śledzenie wymagań uzupełnia pokrycie weryfikacyjne

Przeprowadzanie sprawdzania równoważności między dokumentami programu Word, modelami wirtualnymi i poziomem przesyłania rejestrów (RTL) prawdopodobnie nie będzie możliwe za naszego życia, ale nie musi. Twórcy systemów i zespoły programistyczne już teraz aktywnie wykorzystują identyfikowalność wymagań jako bardzo niezawodną metodę śledzenia zgodności między wymaganiami najwyższego poziomu a wymaganiami na poziomie implementacji, aż do realizacji, weryfikacji i testowania. Ta identyfikowalność jest wspierana przez śledzenie wymagań przy użyciu formatu wymiany wymagań (ReqIF) z platformami takimi jak DOORS i narzędzia Jama Connect.

Chociaż narzędzia te zostały zaprojektowane z myślą o łatwej adaptacji w świecie oprogramowania, nie rozumieją semantyki sprzętowej. Obsługują powiązania „obiektów obcych” w celu połączenia z danymi projektowymi i weryfikacyjnymi, ale ciężar prawidłowego wykonania tych powiązań spoczywa na inżynierach projektujących i weryfikujących. Może nie byłoby tak źle, gdyby było tylko kilkaset obiektów do śledzenia. Ale pomyśl o mapie pamięci, mapie przerwań, mapie multipleksowania IO; mogą one obejmować dziesiątki tysięcy obiektów lub więcej. Ręczna aktualizacja wszystkich tych obiektów poprzez zmiany projektowe i ponowne partycjonowanie staje się niezwykle trudna, jeśli nie niemożliwa.

Lepszym podejściem jest zarządzanie identyfikowalnością, które może łączyć się z narzędziami takimi jak ReqIF po stronie klienta i bezpośrednio z artefaktami śledzonymi przez zespoły projektowe i weryfikacyjne. Zrozumienie semantyki projektowania umożliwia wnioskowanie o powiązaniach między wymaganiami a implementacją oraz ich prawidłowe śledzenie w miarę rozwoju projektu. Ta metoda zapewnia kontrolowane powiązania od specyfikacji klienta, przez wymagania projektowe, aż po realizację SoC.

Jest to identyfikowalność, która może wypełnić cel potwierdzenia weryfikacji przy niewielkim wpływie na zespoły projektowe SoC. Rodzaj wsparcia identyfikowalności, w którym znajdziesz Ślad harmonii Arteris.