TABLE OF CONTENTS:
Co to oznacza, że oprogramowanie wbudowane jest dobre? Zazwyczaj, z perspektywy product ownera, definicja dobrego oprogramowania wbudowanego będzie sprowadzała się do jak najlepszego dopasowania aplikacji do potrzeb klienta, minimalizacji błędów w kodzie i dostarczenia aplikacji na czas. Czy aby na pewno takie podejście jest słuszne?
Bez wątpienia, najważniejszą cechą oprogramowania jest zgodność jego działania z oczekiwaniami klienta, które są opisane przy pomocy wymagań funkcjonalnych i niefunkcjonalnych. Zarówno deweloperowi, jak i product ownerowi zależy na tym, żeby dany system miał wszystkie opisane funkcjonalności i działał jak najsprawniej — bez zawieszania się i luk w bezpieczeństwie.
Kolejną cechą dobrej aplikacji embedded, z punktu widzenia produkt ownera jest dostarczenie oprogramowania na czas. Jeśli nie wykonamy zlecenia w terminie, istnieje ryzyko, że wyprzedzi nas konkurencja albo klient nie będzie chciał kontynuować z nami współpracy. Wtedy cała nasza praca pójdzie na marne. Dlatego ważne jest, żeby jeszcze na etapie rozmów z klientem, przeprowadzić dokładną analizę i zebrać jak najwięcej danych, aby jak najtrafniej określić czas realizacji projektu i nie dopuścić do opóźnień.
Niezawodność oprogramowania to kolejna cecha, którą najczęściej usłyszymy, gdy zapytamy: co to znaczy, że aplikacja jest dobra. Im mniej błędów będzie zawierać, tym bardziej sprawne będzie oprogramowanie. Błędy w aplikacji to istotny problem. Ich reprodukcja, a następnie naprawa jest czasochłonna, a to wpływa na budżet projektu oraz ostateczny wizerunek produktu. Niemniej jednak minimalizacja błędów, to tylko jeden z elementów układanki zwanej jakością kodu i jak się okazuje, niekoniecznie najważniejszy.
Dobre oprogramowanie embedded z perspektywy product ownera:
Wyważenie tych trzech elementów jest, teoretycznie, złotym środkiem do stworzenia dobrego oprogramowania. Brzmi prosto, a jednak takie proste nie jest. Za chwilę dowiesz się, co tak naprawdę możesz zrobić, by tworzyć oprogramowanie dobrej jakości.
Zdarza się, że zaproponowany przez nas czas realizacji nie odpowiada klientowi, a jednocześnie budżet projektu nie pozwala na zwiększenie zespołu. Wówczas, należy przeanalizować, z jakich funkcjonalności możemy zrezygnować, by zmieścić się w wyznaczonym przez klienta czasie i budżecie. Zaczyna się trudna droga do uzyskania kompromisu. Co ważne, takie estymaty są niezbędne, żeby zrealizować projekt.
Kolejny aspekt, to zdefiniowanie ryzyk produktowych i projektowych, a później ich cykliczne analizowanie. Minimalizowanie tych ryzyk to większa szansa na oddanie oprogramowania na czas.
Jeśli przeanalizujemy, które funkcjonalności są priorytetowe, a które mniej ważne, w początkowej fazie projektu, będziemy mogli lepiej zoptymalizować czas wykonania oprogramowania. Możemy zaoszczędzić czas lub przeciwnie – zdarza się, że analiza wykaże, że czas realizacji należy wydłużyć, jeśli zależy nam na zachowaniu odpowiedniego poziomu jakości aplikacji lub utrzymaniu wymaganych przez klienta funkcjonalności.
Prace nad oprogramowaniem powinny rozpocząć się od precyzyjnego i szczegółowego scharakteryzowania jego działania. Tylko wtedy będzie można optymalizować jego wytworzenie. Podstawą dobrego opisu systemu są wymagania definiujące działanie oprogramowania, które dzielą się na funkcjonalne i niefunkcjonalne. Kolejnym krokiem jest architektura oprogramowania wynikająca z określonych wcześniej wymagań. Jeśli ten etap projektu, czyli definicja wymagań i tworzonej na ich podstawie architektury zostanie pominięty lub zaniedbany, konsekwencje dla projektu będą druzgocące.
Dlaczego? Ponieważ wymagania i architektura są fundamentem tworzenia oprogramowania. Niejasne i niepełne dane dadzą deweloperom i testerom pole do własnych interpretacji. A mogą one być różne – raz prawidłowe, innym razem błędne i nie zawsze spójne z tym, jak powinien działać system.
Brak wymagań niefunkcjonalnych dotyczących: użyteczności, niezawodności, wydajności, dostępności, wsparcia, sposobu wdrożenia, skalowalności czy bezpieczeństwa wywołuje niejasności w zakresie działania systemu w tych aspektach. Lepiej mieć wąskie wymagania w każdym aspekcie oprogramowania niż wcale.
Analizując oba wykresy, można zauważyć, że wybór rodzaju testów oprogramowania w projekcie ma bezpośredni wpływ na jakość kodu, a ilość błędów jest tylko jednym z czynników jakościowych oprogramowania. Testujemy więc nie tylko po to, żeby zmniejszyć ilość błędów czy sprawdzić funkcjonalności, ale również, żeby podnieść całościową jakość oprogramowania. Jak widać, jakość aplikacji to bardziej złożone pojęcie.
Teraz możemy zaktualizować wcześniej omówione cechy dobrego oprogramowania.
Tym, co sprawi, że nasze oprogramowanie wbudowane (oprogramowanie embedded) będzie dobre, są skrupulatnie i jasno opisane wymagania systemu i oprogramowania. Ważna jest także spójna architektura wyjaśniająca najważniejsze aspekty rozwiązań działania oprogramowania, które z kolei są niezbędne do wytworzenia aplikacji i jej testowania.
Na bazie zdefiniowanych cech jakościowych aplikacji, należy odpowiednio dobrać poziomy, typy i ilości testów, bo dzięki temu będziemy posiadać metryki opisujące jakość wytworzonego kodu i będziemy mogli określić, czy ta jakość spełnia założone wymagania.
Warto też pamiętać, że podczas każdego procesu wytwarzania oprogramowania najważniejsi są ludzie. Bez ich zaangażowania, nawet najlepsze rozwiązania zawiodą, dlatego zgrany zespół deweloperów i testerów to połowa sukcesu.
