Nasz proces tworzenia 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 szerokie konsultacje i szkolenia z zespołami programistów oprogramowania, rozwijając oprogramowanie układowe dla udanych, długotrwałych produktów i rodzin produktów. Podczas gdy tworzenie solidnej architektury oprogramowania układowego i przeprojektowywanie starszego oprogramowania może być złożonym, trwającym miesiące 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 można zaprojektować system wbudowany lub jego oprogramowanie układowe, niezbędne są jasne wymagania. Dobrze zdefiniowane wymagania określają, co produkt zrobi dla użytkownika, nie opisując szczegółowo, w jaki sposób te cele zostaną osiągnięte. Istotne jest, aby każde stwierdzenie wymagania było jednoznaczne i możliwe do przetestowania. Jednoznaczne stwierdzenie jest jasne i zwięzłe, nie wymaga dalszych wyjaśnień.

Testowalność jest kluczowym czynnikiem; dobrze napisane wymaganie powinno umożliwiać proste tworzenie testów w celu weryfikacji jego spełnienia. Prawidłowy zestaw wymagań składa się ze stwierdzeń zaczynających się od „[produkt] powinien ...”, skupiających się na tym, co jest potrzebne, a nie na tym, jak to jest osiągane, i 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 zmianę po jej ustanowieniu. Wymaga ona starannego rozważenia zamierzonego i dopuszczalnego użycia produktu, aby mieć pewność, że jest wykonywana prawidłowo.

Projekt systemu stanowi warstwę pośrednią tego, jak. Podczas gdy architektura określa szerokie cechy, nie określa nazw funkcji ani zmiennych. Dokument projektu oprogramowania sprzętowego wypełnia te szczegóły, w tym nazwy zadań i obowiązki w określonych podsystemach lub sterownikach urządzeń, używany RTOS (jeśli istnieje) i specyfikę interfejsów między podsystemami.

Faza wdrażania stanowi najniższy poziom hierarchii zarządzania projektem. Gdy interfejsy są jasno zdefiniowane na etapie projektowania, inżynierowie mogą rozpocząć wdrażanie różnych komponentów równolegle. Chociaż wyzwania mogą się różnić w zależności od branży, zazwyczaj mieszczą się w trzech głównych kategoriach: dotrzymywanie terminów w czasie rzeczywistym, testowanie i zarządzanie różnorodnością. Kwestie te są omawiane w trzech ostatnich krokach.

Krok 3: Zarządzanie czasem

Niektóre wymagania dotyczące produktu będą określać wyraźne ograniczenia czasowe. Zazwyczaj produkty obejmują kombinację wymagań nie-czasu rzeczywistego, miękkich-czasu rzeczywistego i twardych-czasu rzeczywistego. Spośród nich miękkie terminy są często najtrudniejsze do jasnego zdefiniowania, przetestowania i wdrożenia. Po zidentyfikowaniu terminów początkowym krokiem w procesie architektonicznym jest przeniesienie jak największej liczby wymagań zależnych od czasu z oprogramowania na sprzęt.

Oddzielenie funkcjonalności w czasie rzeczywistym od głównego oprogramowania zapewnia dwie kluczowe korzyści. Po pierwsze, upraszcza projektowanie i implementację oprogramowania niebędącego oprogramowaniem w czasie rzeczywistym. Dzięki usunięciu ograniczeń czasowych z większości kodu nawet początkujący programiści mogą się przyczynić bez narażania bezpieczeństwa użytkownika. Po drugie, konsolidacja funkcjonalności w czasie rzeczywistym ułatwia analizę i zapewnia, że ​​wszystkie terminy są konsekwentnie dotrzymywane.

Krok 4: Projektowanie z uwzględnieniem testów

Niezbędne jest testowanie każdego systemu wbudowanego na wielu poziomach. W wielu przypadkach testowanie na różnych poziomach jest nie tylko cenne, ale także obowiązkowe.

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

:

1. Testy systemowe potwierdziły, że produkt jako całość spełnia lub przekracza określone wymagania. Zaleca się, aby testy te były opracowywane poza działem inżynierii, chociaż mogą być włączone do wiązki testowej zaprojektowanej przez inżynierów.

2. Testy integracyjne są przeprowadzane w celu zapewnienia, że ​​podzbiory podsystemów, jak opisano na diagramach architektury, współdziałają prawidłowo i przynoszą oczekiwane rezultaty. Te testy są zazwyczaj opracowywane przez zespół testujący 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. Te testy koncentrują się na publicznym API (Application Programming Interface), który komponent oferuje innym komponentom. Zazwyczaj testy jednostkowe są opracowywane przez te same osoby, które piszą testowany kod.

Spośród trzech typów testów testy systemowe są najłatwiejsze do opracowania. Uprząż testowa może być wymagana do testów inżynieryjnych i odbiorczych, ale ten proces jest ogólnie prostszy niż testy integracyjne i jednostkowe, które wymagają większej wewnętrznej widoczności działania urządzenia. Aby usprawnić rozwój, użytkowanie i konserwację testów integracyjnych i jednostkowych, zaleca się zaprojektowanie oprogramowania układowego w sposób zgodny z ramą testów oprogramowania. Najbardziej efektywnym podejściem jest ustrukturyzowanie interakcji między wszystkimi komponentami oprogramowania na poziomach, które zamierzasz testować.

Krok 5: Przygotuj się na zmianę

Podczas fazy architektury oprogramowania sprzętowego, kluczowe jest nadanie priorytetu zarządzaniu różnorodnością funkcji i dostosowywaniem produktu. Aby skutecznie zaplanować zmiany, kluczowe jest najpierw zidentyfikowanie typów zmian, które prawdopodobnie wystąpią w Twoim produkcie. Następnie oprogramowanie sprzętowe powinno zostać zaprojektowane tak, aby uwzględniało te zmiany w możliwie najbardziej efektywny sposób. Dobrze zaprojektowana architektura umożliwia zarządzanie różnorodnością funkcji poprzez pojedynczą kompilację z przełącznikami w czasie kompilacji i/lub w czasie wykonywania, a także umożliwia bezproblemowe dodawanie nowych funkcji bez zakłócania istniejącej funkcjonalności.