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, iż są one choćby 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 uproszczeniu każdy kod, który nie był od początku wytworzony w ramach aktualnego projektu i z zachowaniem obowiązującego procesu wytwarzania systemu 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 choćby kod stworzony przez zewnętrzną firmę na nasze zamówienie.

Szczególnie interesujący 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, iż 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, iż 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, iż 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, iż 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ż, iż 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, iż projekt safety-critical może powstawać choćby kilka lat, a działać choćby 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, o ile nie musimy grzebać w wewnętrznej implementacji dodanego softu, tylko rozszerzać go o potrzebne dodatki. Powinniśmy odciąć go od reszty systemu dzięki 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.