Zwykle przyjmujemy, iż koszt wytworzenia systemu safety-critical spełniającego wymagane normy jest dziesięciokrotnie wyższy, niż zwykły projekt posiadający te same wymagania funkcjonalne. Po przeczytaniu poprzednich części serii powinniście mieć całkiem dobre wyobrażenie skąd biorą się dodatkowe koszty. W tym artykule omówię koszty developmentu, zewnętrznego kodu i narzędzi.
Wykorzystane dane
Do analizy wykorzystam dokument „Cerification Cost Estimates for Future Communication Radio Platforms” wydany przez organizację EUROCONTROL analizujący koszty systemów dla lotnictwa spełniających normy DO-178B dla software’u i DO-254 dla hardware’u. Poziomy bezpieczeństwa DAL (Development Assurance Level) są następujące:
| Level A | Utrata życia pasażerów, zniszczenie samolotu |
| Level B | Duży negatywny wpływ na bezpieczeństwo i osiągi samolotu, możliwe poważne obrażenia pasażerów |
| Level C | Znaczne zmniejszenie marginesu bezpieczeństwa pilotów, możliwe lekkie obrażenia pasażerów |
| Level D | Niewielkie zmniejszenie marginesu bezpieczeństwa pilotów, możliwe niedogodności pasażerów i wydłużenie lotu. |
| Level E | Brak negatywnych skutków |
O poziomach bezpieczeństwa więcej można przeczytać w jednej z wcześniejszych części cyklu:
SLOC/h – Ilość linii kodu na godzinę
Ilość kodu produkcyjnego w przeliczeniu na godzinę pracy developera dla poszczególnych poziomów DAL przedstawia wykres:
W pierwszym odruchu możecie sobie pomyśleć, iż to jakieś brednie. Jaki doświadczony developer pisałby 12 linii kodu na godzinę? Musicie jednak pamiętać, iż wartość SLOC/h (software lines of code per hour) jest obliczana jako ilość ostatecznego kodu produkcyjnego (bez pustych linii i komentarzy) podzielona przez ilość osobogodzin wszystkich osób pracujących nad projektem. Uwzględnia więc ona nie tylko samo pisanie kodu, ale również projektowanie, dokumentację, prototypy, testy, refactoring, meetingi, zarządzanie, certyfikację i wszystkie inne aktywności wykonywane w czasie projektu.
W temacie SLOC trafiłem również w sieci na interesujące porównanie, które działa na wyobraźnię. Koszt wytworzenia pojedynczej linii kodu produkcyjnego zawiera się w przedziale 10$-45$. Oznacza to, iż już 1000 linii kodu może być wartych tyle samo co kilogram złota.
Skąd biorą się różnice między poziomami bezpieczeństwa?
W dokumencie znajdziemy również odpowiedź skąd biorą się różnice między poszczególnymi poziomami DAL. Zostały one przedstawione na kolejnym wykresie:
Dołączono również tabelę opisującą dodatkowe kroki wymagane na poszczególnych poziomach:
Jak widać najwięcej dodatkowej pracy związanej z zapewnieniem wymaganego poziomu DAL dotyczy weryfikacji. Nie oznacza to oczywiście jedynie testowania gotowego rozwiązania. O niektórych zadaniach weryfikacyjnych trzeba pomyśleć już na samym początku projektu. Dobrym przykładem jest tutaj Traceability, czyli możliwość prześledzenia rozwoju funkcjonalności od wymagań przez rozwiązania architektoniczne po implementację i testy.
Gdzie ponosimy koszty?
Koszt możemy ponosić na dwa sposoby:
- Czas potrzebny na stworzenie własnego rozwiązania.
- Kupienie gotowego softu i narzędzi.
Wbrew pozorom druga opcja jest często tańsza mimo, iż ceny wydają się kosmiczne. Potwierdzenie możemy znaleźć również w dokumencie. Jest tam tabela z wyliczeniem ilości osobodni potrzebnych do realizacji przykładowego projektu spełniając poszczególne poziomy DAL (Table 9, strona 59-60). Aby spełnić najwyższy poziom DAL A potrzeba około 46000 mandayów. Z tego 42000 zajmują 2 komponenty – Stos IPv6 i ORB (Object Request Broker). Korzystając z gotowych rozwiązań jesteśmy więc w stanie zaoszczędzić teoretycznie 90% czasu projektu!
Poza softem możemy również kupić narzędzia automatyzujące pracę. Ułatwiają one zachowanie procesu wytwarzania systemu wymaganego przez normę. Toole tego typu to najczęściej prawdziwe kombajny zawierające ogromną ilość opcji i mające równie ogromną cenę.
Podejmując decyzję o wyborze takiego narzędzia staramy się porównać jego cenę z kosztem robienia wszystkiego manualnie. Najczęściej takie kalkulacje mocno mijają się z rzeczywistością. Mamy tendencję do robienia zbyt optymistycznych założeń i szacujemy zbyt mały koszt pracy. Najczęstszą przyczyną nietrafionych estymat jest zakładanie, iż raz wykonanych czynności nie będziemy musieli powtarzać. Niestety zmiany w projekcie, czy wydawanie nowych wersji wymusza na nas kolejne przejścia cyklu. Napisanie własnych narzędzi albo robienie wszystkiego za każdym razem manualnie na dłuższą metę bardzo często się nie opłaca. Poza tym dostajemy support, a zaoszczędzony czas możemy przeznaczyć na inne aktywności.
