Specyfikacja w systemach Embedded

Podczas realizacji dowolnego projektu informatycznego, każdy z nas ma lub miał styczność ze specyfikacją techniczną. O ile specyfikacja systemu, a właściwie jakość specyfikacji, w każdym projekcie jest ważna, to w projektach embedded jej rola jest szczególnie istotna. Poniżej postaram się opisać temat bardziej szczegółowo. Zacznijmy jednak od zdefiniowania, co to jest specyfikacja ogólnie, nie tylko w systemach embedded. Zgodnie ze słownikiem ISTQB oraz standardem IEEE 610:

Definicja

specyfikacja – dokument, który określa, najlepiej w sposób kompletny, precyzyjny i możliwy do weryfikacji sposób, wymagania, projekt, zachowanie lub inne właściwości modułu, lub systemu, oraz często procedury sprawdzania, czy te warunki zostały spełnione.

Ze swojej strony mogę dodać, że podstawową cechą dobrej specyfikacji technicznej jest jej jednoznaczność. Każda możliwość interpretacji stwarza poważne zagrożenia w realizacji projektu. Dotyczy to każdej specyfikacji technicznej, a w szczególności tej w systemach embedded.

Oczywiście, każdy z nas wie, że nie ma specyfikacji idealnej, tak samo, jak nie ma idealnego kodu, idealnych testów, idealnego … (w miejsce trzech kropek można wstawić dowolną rzecz). Dlatego też w każdym możliwym momencie powinniśmy dążyć do polepszenia jakości dokumentu, wykorzystując do tego wszystkie możliwe sposoby, takie jak inspekcje, przeglądy formalne czy nieformalne, a także poprzez bieżące zgłaszanie zauważonych niedomówień, rozbieżności, czy innych błędów. Zwracanie na to uwagi jest szczególnie ważne, biorąc pod uwagę fakt, że nawet w dzisiejszych czasach nietrudno znaleźć osoby, które uważają przeglądy specyfikacji za elementy mało istotne, opcjonalne…

Koszt naprawy błędu

Kolejnym czynnikiem potwierdzającym jak ważne są inspekcje czy przeglądy, jest koszt naprawy znalezionego defektu. Jak wiemy znalezienie błędu na poziomie specyfikacji, wymaga wykonania poprawek jedynie w tym dokumencie, dzięki czemu jest stanowczo tańsze w jego naprawie niż znalezienie błedu na poziomie kodowania, czy po wdrożeniu. Niektóre źródła podają, że usunięcie błędów znalezionych po wdrożeniu jest nawet 100-krotnie droższe od ich naprawy na poziomie specyfikacji. Biorąc dodatkowo pod uwagę specyfikę systemów embedded uważam, że nie jest to przesadzona wartość.

Znakomita większość systemów opartych na technologiach webowych czy mobilnych umożliwia ciągłą ingerencję w oprogramowania. Dzięki temu realne jest naprawienie każdego błędu, znalezionego w dowolnym momencie. Nawet gdy projekt został zakończony oraz oddany dla klienta, jest możliwość wykonania aktualizacji, czy wypuszczenia nowszej wersji z usprawnieniami.

Natomiast jak sprawa wygląda w systemach embedded?

Wariant I

Błąd wprowadzony podczas tworzenia specyfikacji znajdujemy w trakcie kodowania lub w trakcie testów. W tej sytuacji istnieje możliwość szybkiego zareagowania oraz wykonania działań naprawczych, takich jak:

przydzielenie zwiększonych zasobów,
zmiana priorytetu działań,
przesunięcie terminu wydania.

Wariant II

Błąd wprowadzony podczas tworzenia specyfikacji znajdujemy po wydaniu.

W tym przypadku sprawa znacznie się komplikuje, gdyż nie jesteśmy w stanie szybko zareagować i usunąć defekt bez ponoszenia poważnych kosztów, a niejednokrotnie strat pod kątem wizerunkowym. W przypadku gdy urządzenie posiada stały dostęp do internetu oraz umożliwia zdalną aktualizację, w stosunkowo szybki sposób można wysłać do urządzeń łatkę z poprawką lub nowy soft. Co, jeśli urządzenie nie jest dostępne? Wtedy sprawa się znacznie komplikuje, a koszty w bardzo szybkim tempie rosną.

Przykładowe działania:

wycofanie partii z błędem – po aktualizacji ponowne wypuszczenie na rynek,
w przypadku urządzeń przenośnych/mobilnych – zgłoszenia serwisowe do użytkowników, o akcji serwisowej
w przypadku urządzeń stałych/nieruchomych – wysłanie serwisu w celu ręcznej aktualizacji

Jak widać na wykresie, koszty usunięcia błędu po wydaniu są znaczenie wyższe niż na wcześniejszych etapach realizacji projektu. Jedynym sposobem, aby się przed tym ustrzec jest wdrożenie testowania w jak najwcześniejszym etapie życia projektu. Bardzo istotną rolę pełnią wszelkiego rodzaju przeglądy formalne oraz nieformalne, a także inspekcje dokumentacji.

Patrząc w przyszłość, można zauważyć, że w szybkim tempie wzrasta liczba urządzeń embedded podłączonych do sieci internetowej, a co za tym idzie, umożliwiających zdalną aktualizację. Jednak jestem przekonany, że nigdy ten odsetek nie osiągnie 100% w przypadku systemów wbudowanych.