Stale rosnąca skala integracji, nowe chipy o wysokiej funkcjonalności, coraz popularniejsze SoC-e, czyli systemy na krzemie, ułatwiają pracę i bezsprzecznie można uznać, że efektem ich wejścia na rynek jest to, że warstwę sprzętową aplikacji projektuje się szybciej. Wiele funkcji w systemach elektronicznych realizowanych jest metodami programowymi, czyli hardware jest maksymalnie prosty, kosztem rozbudowanego oprogramowania. Ma to sens, bo za chipy płaci się za każdą sztukę, a za oprogramowanie tylko raz oraz tak projektuje się szybciej.
Chęć bycia pierwszą firmą z produktem na rynku oraz wiele innych czynników o charakterze biznesowym związanym z finansowaniem projektu powodują, że oczekiwanie na skrócenie czasu projektowania przenosi się też na warstwę firmware. Skoro hardware projektuje się szybko, to dla wielu tak samo powinno być z oprogramowaniem. W efekcie na rynku dominuje często podejście, że można wypuścić produkt z kodem napisanym byle jak, nawet kompletnie niedopracowanym i z licznymi błędami, a potem przez szereg kolejnych aktualizacji i poprawek goni się czas zaoszczędzony, a raczej "skrócony" w projekcie.
Takie podejście dominuje w sprzęcie konsumenckim, ale można coraz częściej podać przykłady z branż profesjonalnych, które czerpią garściami ze sprzętu powszechnego użytku także w takim negatywnym zakresie.
Idąc tym tropem, można oczekiwać, że któryś z producentów w końcu wypuści na rynek system embedded całkowicie bez firmware'u, które nabywca będzie musiał sobie pobrać i zainstalować po kupnie. Niewątpliwie takie podejście w świetle powyższych rozważań o przyspieszaniu cyklu projektowego wydaje się efektywne.
Niemniej badania pokazują, że patrząc na wszystko inne poza szybkością wejścia produktu na rynek, w tym koszty projektu, jakość produktu, zadowolenie użytkowników widać, że wypuszczenie wersji z oprogramowaniem dopracowanym w każdym szczególe jest korzystniejsze. Co więcej, zdaniem specjalistów produkt dopracowany nie pojawi się na rynku wiele później, bo z czasem w firmach tworzy się wysoka kultura pracy i system działań opisywanych jako zapewnienie jakości, które eliminują bałaganiarstwo i bylejakość bez degradowania zbytniego tempa pracy. Firma taka zyskuje czas w innych obszarach, np. w prototypowaniu, gdzie nie trzeba wykonywać wielu wersji próbnych, w badaniach, certyfikacji itd.
Zysk na czasie projektowania w tym przypadku pojawia się dzięki zaawansowanym narzędziom projektowym, dobremu planowaniu i sprecyzowanym wymaganiom, które nie powstają podczas pracy na bieżąco, tylko są wypracowane na początku. Czas oszczędza się też w wyniku doboru architektury systemu, interfejsu użytkownika, wykorzystania pakietów bibliotek i systemów operacyjnych, stosów, czyli dorobku pracy innych wykorzystywanych na zasadzie kupna licencji.
Okazuje się, że pisanie kodu na kolanie, a potem jego mozolne poprawianie w kolejnych aktualizacjach jest też kosztowniejsze w porównaniu z pracą staranną, bo liczba błędów rośnie wykładniczo z tempem redukcji czasu pracy nad aplikacją. Liczy się ponadto organizacja pracy, czyli na przykład dobre zgranie zespołu, pozwalające na tworzenie firmware'u równolegle ze sprzętem bez czekania na szczegóły i gotowe schematy.
Na koniec warto zauważyć, że postawienie na jakość w przypadku oprogramowania oznacza, że praca zespołu projektowego obarczona jest w takim przypadku mniejszym ryzykiem. Gotowe, przetestowane i certyfikowane biblioteki i oprogramowanie projektowe, większy zespół pracowników umożliwiający podział zadań i generalne oparcie się na wysiłku większej całości ogranicza ryzyko przeoczenia grubych i poważnych błędów. Spokojny sen też ma swoją cenę.
Robert Magdziak
