W większości projektów, gdy mamy możliwość wykorzystania jakiegoś istniejącego rozwiązania, w ogóle się nie zastanawiamy. Dużo publicznego kodu znajdziemy na GitHubie, a w JavaScripcie wychodzi tyle nowych bibliotek, że są one nawet częścią pijackiej gry. Jak już pewnie się domyślacie – w systemach safety-critical sytuacja jest zgoła odmienna. Użycie zewnętrznego kodu podlega specjalnym procedurom i w normach nazywane jest właśnie tytułowym akronimem SOUP, czyli Software of Unknown Provenance, lub Software of Uncertain Pedigree. Nazwy te od razu zwracają uwagę na podstawowy problem tego softu – jego nieznane pochodzenie, historię i proces wytwarzania.
Co zalicza się do SOUP?
Każda norma oczywiście zawiera definicję co rozumie przez SOUP. Czasem używane są również inne nazwy, jak na przykład COTS (Commercial off the Shelf). W skrócie każdy kod, który nie był od początku wytworzony w ramach aktualnego projektu i z zachowaniem obowiązującego procesu wytwarzania oprogramowania jest uznawany za SOUP. Może to być więc:
- Projekt open-source z internetu.
- Oprogramowanie płatne.
- Kod wzięty z innego projektu.
- A nawet kod stworzony przez zewnętrzną firmę na nasze zamówienie.
Szczególnie ciekawy jest ostatni punkt. NASA ma swoje checklisty z wymaganiami stawianymi zewnętrznym kontraktorom. Źle widziana jest na przykład praca w dużych nadgodzinach. Czyli SpaceX na przykład by ich nie spełnił 😀 Jest to uzasadnione wcześniejszymi doświadczeniami NASA, po których doszli do wniosku, że koszt błędów popełnianych przez zmęczonych developerów – skutkujący na przykład niepowodzeniem misji kosztującej miliardy dolarów – jest większy niż korzyści z większej ilości mandaysów.
Nieraz jesteśmy tak przyzwyczajeni do używanych bibliotek, że w ogóle nie traktujemy ich jako zewnętrzny soft. Dobrym przykładem są tu biblioteki standardowe języka jak choćby C stdlib. To samo tyczy systemów operacyjnych, systemów plików, stosów TCP/IP, bibliotek kryptograficznych i wszelkiego innego kodu.
Typowe problemy
W przypadku takiego softu wziętego z zewnątrz zwykle musimy się mierzyć z:
- Dokumentacją nie spełniającą wymagań norm.
- Brakiem dostępu do kodu źródłowego (w przypadku płatnego softu w formie binarnej).
- Niewystarczającym supportem.
- Brakiem informacji o procesie wytwarzania np. jak tworzono architekturę, czy robiono testy, czy była statyczna analiza.
- Integracją z resztą projektu.
Oczywiście skoro decydujemy się na użycie zewnętrznego softu, musimy zapewnić zgodność z wymaganiami stawianymi przez normę. Oznacza to, że musimy sami wykonać odpowiednie testy i stworzyć wymagane dokumenty. Support producentów softu może okazać się tutaj bardzo pomocny. Często okazuje się wręcz, że wybranie wersji komercyjnej jest tańsze niż użycie darmowego softu i wzięcie całego ciężaru biurokratycznego na siebie.
Co brać pod uwagę przy wyborze SOUP?
Wiemy już, że decyzja o wykorzystaniu zewnętrznego kodu wcale nie musi być taka prosta. Niesie ona za sobą pewne konsekwencje i nakłada na nas nowe obowiązki. Dlatego wybór takiego softu musi być dokonany mądrze. Pomagają w tym różne dostępne w internecie guideline’y takie jak na przykład Software Safety Guidebook od NASA. Na co więc powinniśmy patrzeć?
Stabilność
Po pierwsze musimy ocenić, czy soft, którego chcemy użyć, jest stabilny. W tym celu musimy odpowiedzieć na pytania:
- Jak często wychodzą nowe wersje?
- Czy API jest stabilne?
- Jak długo już projekt jest rozwijany?
- Ile osób z niego korzysta?
- Ile osób go rozwija?
Jeżeli biblioteka jest aktywnie, długo rozwijana i używana przez wiele osób, jej wiarygodność wzrasta.
Wymagania z norm
Kolejny zestaw pytań dotyczy wymagań stawianych przez normy. Tutaj musimy wziąć pod uwagę:
- Jakość ogólnodostępnej dokumentacji.
- Poziom wsparcia technicznego – szczególnie czy jest w stanie pomóc przy spełnianiu norm.
- Czy mamy dostęp do kodu źródłowego.
- Sposób testowania projektu.
- Proces fixowania błędów.
- Jak długo wspierane są starsze wersje?
Ostatni z tych punktów jest ważniejszy niż mogłoby się wydawać. W safety-critical zarządzanie wersjami również jest mocno sformalizowane i nie dodajemy od razu każdej aktualizacji. Wymagana jest głębsza analiza zmian i często decydujemy się pozostać przy jednej konkretnej wersji. Wtedy przyda się wsparcie do starszej wersji, tym bardziej, że projekt safety-critical może powstawać nawet kilka lat, a działać nawet i 20 lat.
Integracja
Następny zestaw pytań dotyczy łatwości integracji z naszym projektem. Tutaj musimy się zastanowić nad kwestiami takimi jak:
- Możliwość rozszerzania i modyfikacji softu.
- Czy znalezione bugi dodajemy do kodu, czy zgłaszamy i czekamy na nową wersję z fixem?
- Czy da się wyłączyć nieużywane funkcje?
- Jak bardzo uzależniamy się od zewnętrznego softu? Czy jest to biblioteka dołączana do naszego kodu, czy framework odpalający nasz kod. Preferowana jest oczywiście opcja numer jeden.
- Czy musimy dopisać jakieś brakujące funkcje?
Najlepiej, jeżeli nie musimy grzebać w wewnętrznej implementacji dodanego softu, tylko rozszerzać go o potrzebne dodatki. Powinniśmy odciąć go od reszty systemu za pomocą odpowiedniej warstwy abstrakcji zmniejszając do minimum bezpośrednie zależności.
Podsumowanie
Ograniczenia dotyczące wykorzystania istniejącego softu w safety-critical są dość restrykcyjne. Jednak na pewno nie można odmówić im sensu. Przynajmniej część z nich może być również wykorzystana w zwykłych projektach jako odpowiedź na hype driven development. Oczywiście bez tych wszystkich punktów wymuszanych przez normy.
Dodaj komentarz