Inżynieria systemów dla programistów

Wstęp

Ten artykuł był dla mnie jednym z trudniejszych do napisania, w tej serii. Wynika to z mojego poczucia, że programiści to grupa inżynierska z największymi wrodzonymi lub nabytymi skłonnościami do stosowania inżynierii systemów. W moim mniemaniu wynika to z konstrukcji umysłowej osób zostających programistami oraz ze specyfiki procesu tworzenia oprogramowania.

Z mojego doświadczenia pracy z programistami (głównie programującymi systemy wbudowane – ang. embedded software), ich naturalna potrzeba zastosowania procesów i narzędzi inżynierii systemów, niejednokrotnie jest nieświadoma i spontaniczna, postrzegana jako „normalny sposób działania”. W związku z tym, mam nadzieję, że nawet jeśli ten artykuł nie przyniesie programistom żadnej nowej wiedzy to przynajmniej uświadomi im, że w praktyce nierzadko wykonują pracę inżyniera systemów lub posługują się jego narzędziami.

Definiowanie wymagań dla oprogramowania

Tak jak już wiemy z innych moim artykułów na temat inżynierii wymagań, wymagania należy identyfikować i definiować na początku projektu, i nie można tego kroku przeskakiwać, ani przyspieszać.

Ale...

W zależności od tego z jakim zastosowaniem oprogramowania się mierzymy, oraz kto jest docelowym odbiorcą tworzonego systemu, proces definiowania wymagań można modyfikować. Otóż, inaczej będziemy tworzyli wymagania na oprogramowanie komputera pokładowego satelity, a inaczej oprogramowanie nowej aplikacji mobilnej umożliwiającej płatności on-line.

W pierwszym przypadku możemy iść za tropem wytyczonym przez tradycyjny proces tworzenia wymagań w projektach realizowanych w duchu modelu kaskadowego (ang. waterfall), tj. „siadamy i piszemy wymagania tak długo, aż stwierdzimy, że zaadresowaliśmy wszystkie wymagane funkcje systemu.”

Inaczej się sprawa ma, gdy użytkownik tworzonego systemu ma bezpośredni kontakt z jego oprogramowaniem. Tym bardziej, gdy nie jest on specjalistą, a „zwykłym codziennym użytkownikiem".

Natrafiamy tutaj na kilka problemów. Pierwszym z nich jest utrudniony dostęp do użytkowników, który to jest niezbędny w procesie identyfikowania kluczowych wymagań. Po drugie, nawet jeśli uda nam się dotrzeć do takiego użytkownika, a w praktyce powinna to być cała grupa użytkowników, to nie jest powiedziane, że będą oni wiedzieli czego potrzebują.

Tutaj zahaczamy o zasadniczy problem, z którym wszyscy inżynierowie systemów muszą się mierzyć, ale w spotęgowanej skali. Rzadko kiedy klient czy użytkownik wiedzą czego potrzebują. Zadaniem inżynierii systemów, jest dojście do tego w metodyczny sposób.

Praktyka realizacji projektów obejmujących tworzenie oprogramowania, udowadnia, że najlepszym sposobem definiowania wymagań dla oprogramowania jest podejście iteracyjne i inkrementalne. Oznacza to, że na początku projektu identyfikujemy kluczowe funkcje całości systemu oraz podstawowe założenia projektowe, po czym rozpoczynamy wstępną implementację. Pierwsze wersje tak opracowanego systemu poddaje się testom z potencjalnymi użytkownikami, a na bazie informacji zwrotnych poprawia się pierwotne założenia i je uszczegóławia. Taki proces powinien zostać powtórzony kilku albo kilkunastokrotnie. Im bardziej złożony system, tym więcej razy.

Jest to działanie w duchu metodyki zwinnego (ang. agile) realizowania projektów.

Taki sposób realizowania projektów daje się stosować w przypadku takich technologii jak oprogramowanie, w których wykonywanie krótkich pętle iteracji jest możliwe. Znacznie trudniej to przychodzi, gdy mamy do czynienia z fizycznym sprzętem (ang. hardware), np. płytką elektroniczną lub strukturą mechaniczną.

Architektura zachowania

Mając określone kluczowe wymagania przechodzimy do tworzenia architektury zachowania systemu. W tym obszarze możemy korzystać z ad-hoc diagramów, ale w praktyce przydatne są języki modelowania takie jak UML (Unified Modeling Language) czy SysML (System Modeling Language). Pozwalają one w ustandaryzowany sposób zdefiniować zachowanie i strukturę systemu, bądź jego oprogramowania.

Warto tutaj wspomnieć, że UML został stworzony przez programistów, dla programistów, a z czasem stał się podstawą do opracowania SysML, który z kolei powstał dla inżynierów systemów. W tym sensie programiści byli pionierami w zakresie modelowania systemów - w tym przypadku oprogramowania.

Wracając do architektury zachowania. Kluczowe jest uchwycenie w niej głównych funkcji systemu, które odpowiadają na potrzeby zdefiniowane w wymaganiach. Takie funkcje można stopniowo rozbijać na bardziej granularne funkcje systemu, aż do pełnego zdefiniowana tego co system robi, oraz jak to robi. Należy pamiętać tutaj o świętej granicy pomiędzy architekturą systemu i jego implementacją. Pierwsze leży w zakresie inżynierii systemów, a drugie, w tym przypadku, w zakresie inżyniera oprogramowania.

Jest to o tyle ważne, że każdą architekturę można zaimplementować na więcej niż jeden sposób.

Rysunek 1 przedstawia przykładowy diagram aktywności, zgodny z UML.

W tym procesie tworzenia architektury zachowania, ważne jest żeby utrzymywać śledzenie pomiędzy wymaganiami (tworzonymi w ten iteracyjny sposób opisany powyżej) oraz elementami architektury zachowania. Dzięki temu będziemy spokojni o to, że każda z wymaganych funkcji znalazła swoje odzwierciedlenie w architekturze.

Rysunek 1 Przykład diagramu aktywności UML

Opowieść o tworzeniu architektury i użycia UML wykracza poza zakres tego co chciałem w tym artykule przekazać, więc tutaj się zatrzymam.

Jak być przygotowanym na najgorsze?

O Failure Mode and Effects Analysis (FMEA) pisałem już w artykule o inżynierii systemów dla mechatroników. Skupiłem się wtedy na aspektach sprzętowych, odpowiednich dla projektu elektronicznego. W przypadku oprogramowania, taka analiza powinna być jednym z kluczowych elementów pracy zespołu inżynierskiego.

Dlaczego?

Taka analiza pozwala zidentyfikować zdarzenia, w które wykraczają poza nominalny sposób działania tworzonego systemu. Mówimy tutaj zdarzeniach wynikających, tak z kwestii sprzętowych, np. typu mikrokontrolera, na którym oprogramowanie jest wykonywane, jak i kwestii środowiskowych, np. typu systemu operacyjnego.

Nie jest wyzwaniem stworzyć system, który działa poprawnie kiedy wszystkie operacje są wykonywanie poprawnie. Sztuką jest stworzyć system, który albo nie pozwoli popełnić użytkownikowi błędu, albo będzie w stanie sobie z tymi błędami poradzić.

Sytuacja silnie zależy od poziomu wymaganej autonomii systemu, co ponownie jest związane od typu tworzonego systemu. Oprogramowanie komputera pokładowego satelity będzie się pod tym względem różniło od wspomnianej aplikacji do płatności on-line.

Oprogramowanie satelity musi poradzić sobie z błędami sprzętowymi, np. zmianą wartości logicznej bitów w mikrokontrolerze spowodowanej promieniowaniem kosmicznym, jak i niepoprawnymi komendami dochodzącymi od operatora z Ziemi.

FMEA pozwala zidentyfikować te wszystkie niepożądane zdarzenia, ocenić ich prawdopodobieństwo oraz skalę ich potencjalnych skutków. Stanowi też miejsce, w którym można zaproponować działania korekcyjne lub zapobiegające wystąpieniu takich zdarzeń. Kompletny proces określający to jak sobie radzić z błędami określa się w ramach Fault Detection, Isolation and Recovery (FDIR), czyli przekładając na polski: Wykrycie błędu, zapobiegnięcie jego propagacji oraz sposobu powrót do stanu pracy nominalnej.

Cały ten temat nabiera obecnie jeszcze większej wagi, w dobie tzw. systemów definiowanych oprogramowaniem (ang. software-defined systems). Takie systemy stanowią sprzętową platformę, która pozwala na dynamiczną ich modyfikację poprzez zmianę oprogramowania. Skutkuje to przeniesieniem ciężaru implementacji z poziomu sprzętowego na poziom „kodu".

Podsumowanie

Chciałbym was zostawić z następującymi konkluzjami z tego artykułu:

• duża część programistów, zwłaszcza tych doświadczonych, sama zabiega o wykonanie inżynierii systemów, nawet nieświadomie

• stworzyli UML na swoje potrzeby, więc duch inżynierii systemów jest im bliski

• ze względu na rosnącą złożoność oprogramowania programiści będą potrzebowali więcej i więcej wsparcia systemowego