Nasz proces rozwoju oprogramowania sprzętowego opiera się na podejściu składającym się z pięciu etapów

W ciągu ostatnich kilku lat przeprowadziliśmy szeroko zakrojone konsultacje i szkolenia z zespołami programistów, tworząc oprogramowanie układowe dla udanych, trwałych produktów i rodzin produktów. Chociaż tworzenie solidnej architektury oprogramowania układowego i przebudowa starszego oprogramowania może być złożonym, wielomiesięcznym procesem, zidentyfikowaliśmy pięć kluczowych kroków, które tworzą podejście krok po kroku, umożliwiając naszemu zespołowi rozpoczęcie pracy na właściwej ścieżce.

Krok 1: Określ wymagania

Zanim będzie można zaprojektować system wbudowany lub jego oprogramowanie układowe, niezbędne są jasne wymagania. Dobrze zdefiniowane wymagania określają, co produkt będzie robił dla użytkownika, nie precyzując, w jaki sposób te cele zostaną osiągnięte. Kluczowe jest, aby każde stwierdzenie wymagania było jednoznaczne i możliwe do przetestowania. Jednoznaczne stwierdzenie jest jasne i zwięzłe, niewymagające dalszych wyjaśnień.

Testowalność jest kluczowym czynnikiem; dobrze sformułowane wymaganie powinno umożliwiać proste tworzenie testów weryfikujących jego spełnienie. Prawidłowy zestaw wymagań składa się ze stwierdzeń zaczynających się od „[produkt] powinien…”, koncentrujących się na tym, co jest potrzebne, a nie na tym, jak to osiągnąć, oraz zapewniających przejrzystość i testowalność. W związku z tym skuteczna architektura opiera się na dobrze zdefiniowanych wymaganiach.

Krok 2: Rozróżnij architekturę i design

Z naszego doświadczenia wynika, że ​​wielu inżynierów i ich menedżerów ma trudności z rozróżnianiem różnych aspektów inżynierii oprogramowania sprzętowego. Architektura systemu reprezentuje najwyższy poziom JAK, definiując trwałe cechy produktu i utrudniając wprowadzanie zmian po ich wprowadzeniu. Wymaga ona starannego rozważenia przeznaczenia i dopuszczalnych zastosowań produktu, aby zapewnić jego prawidłowe działanie.

Projekt systemu stanowi warstwę pośrednią. Architektura określa ogólne cechy, ale nie określa nazw funkcji ani zmiennych. Dokument projektu oprogramowania sprzętowego uzupełnia te szczegóły, w tym nazwy zadań i obowiązki w ramach poszczególnych podsystemów lub sterowników urządzeń, używany system operacyjny czasu rzeczywistego (RTOS) (jeśli występuje) oraz specyfikę interfejsów między podsystemami.

Faza wdrożenia stanowi najniższy poziom hierarchii zarządzania projektem. Gdy interfejsy są jasno zdefiniowane na etapie projektowania, inżynierowie mogą rozpocząć równoległe wdrażanie różnych komponentów. Chociaż wyzwania mogą się różnić w zależności od branży, zazwyczaj można je podzielić na trzy główne kategorie: dotrzymywanie terminów, testowanie i zarządzanie różnorodnością. Kwestie te są omawiane w trzech ostatnich krokach.

Krok 3: Zarządzanie czasem

Niektóre wymagania produktowe określają wyraźne ograniczenia czasowe. Zazwyczaj produkty obejmują kombinację wymagań nie-czasu rzeczywistego, wymagań-czasu rzeczywistego i wymagań-czasu rzeczywistego. Spośród nich, terminy-czasy rzeczywiste są często najtrudniejsze do jasnego zdefiniowania, przetestowania i wdrożenia. Po ustaleniu terminów, pierwszym krokiem w procesie architektonicznym jest przeniesienie jak największej liczby wymagań czasowych z oprogramowania na sprzęt.

Oddzielenie funkcjonalności czasu rzeczywistego od głównego oprogramowania zapewnia dwie kluczowe korzyści. Po pierwsze, upraszcza projektowanie i wdrażanie oprogramowania nieobsługującego czasu rzeczywistego. Dzięki usunięciu ograniczeń czasowych z większości kodu, nawet początkujący programiści mogą wnieść swój wkład bez narażania bezpieczeństwa użytkownika. Po drugie, konsolidacja funkcjonalności czasu rzeczywistego ułatwia analizę i zapewnia dotrzymanie wszystkich terminów.

Krok 4: Projektowanie z uwzględnieniem testów

Testowanie każdego systemu wbudowanego na wielu poziomach jest niezbędne. W wielu przypadkach testowanie na różnych poziomach jest nie tylko cenne, ale wręcz obowiązkowe.

Do najczęściej przeprowadzanych poziomów testowania należą

:

1. Testy systemowe potwierdziły, że produkt jako całość spełnia lub przewyższa określone wymagania. Zaleca się, aby testy te były opracowywane poza działem inżynieryjnym, chociaż mogą być one włączone do zestawu testowego zaprojektowanego przez inżynierów.

2. Testy integracyjne przeprowadza się w celu zapewnienia, że ​​podzbiory podsystemów, zgodnie z diagramami architektury, współdziałają prawidłowo i przynoszą oczekiwane rezultaty. Testy te są zazwyczaj opracowywane przez zespół testerów lub osobę z działu inżynierii oprogramowania.

3. Testy jednostkowe gwarantują, że poszczególne komponenty oprogramowania, zdefiniowane na etapie pośredniego projektowania, działają zgodnie z przeznaczeniem. Testy te koncentrują się na publicznym interfejsie API (Application Programming Interface), który dany komponent udostępnia innym komponentom. Zazwyczaj testy jednostkowe są opracowywane przez te same osoby, które piszą testowany kod.

Spośród trzech rodzajów testów, testy systemowe są najłatwiejsze do opracowania. Do testów inżynieryjnych i odbiorczych (FDA) może być wymagana grupa testów, ale proces ten jest zazwyczaj prostszy niż testy integracyjne i jednostkowe, które wymagają większej widoczności wewnętrznej działania urządzenia. Aby usprawnić tworzenie, użytkowanie i utrzymanie testów integracyjnych i jednostkowych, zaleca się zaprojektowanie oprogramowania układowego w sposób zgodny z frameworkiem testów oprogramowania. Najskuteczniejszym podejściem jest ustrukturyzowanie interakcji między wszystkimi komponentami oprogramowania na poziomach, które zamierzasz testować.

Krok 5: Przygotuj się na zmianę

Na etapie projektowania architektury oprogramowania sprzętowego priorytetem jest zarządzanie różnorodnością funkcji i dostosowywanie produktu. Aby skutecznie planować zmiany, kluczowe jest najpierw zidentyfikowanie rodzajów zmian, które prawdopodobnie wystąpią w produkcie. Następnie oprogramowanie sprzętowe powinno zostać zaprojektowane tak, aby uwzględniało te zmiany w jak najbardziej efektywny sposób. Dobrze zaprojektowana architektura pozwala na zarządzanie różnorodnością funkcji w ramach jednej kompilacji z przełącznikami w czasie kompilacji i/lub wykonania, a jednocześnie umożliwia płynne dodawanie nowych funkcji bez zakłócania istniejącej funkcjonalności.