Inżynieria systemów komputerowych Inżynieria systemów to czynność specyfikowania, projektowania, implementowania, weryfikowania, wdrażania i pielęgnacji systemów postrzegana jako całość.

Cele Dowiedzieć się, dlaczego oprogramowanie w systemie pozostaje pod wpływem ogólniejszych zagadnień inżynierii systemów. Być wprowadzonym w pojęcia pojawiających się właściwości systemu takich jak niezawodność, efektywność, bezpieczeństwo i zabezpieczenia. Rozumieć, dlaczego w czasie projektowania systemu należy zbadać jego środowisko. Rozumieć inżynierię systemów i proces zaopatrywania w system.

Zawartość Pojawiające się właściwości systemu Systemy i ich środowiska Modelowanie systemu Proces inżynierii systemów Zaopatrywanie w system

Co to jest system? System jest celową kolekcją powiązanych ze sobą komponentów, które współpracują, aby osiągnąć pewien cel. Bardzo prosty system, na przykład pióro, jest zrobiony z trzech lub czterech komponentów sprzętowych. System kontroli lotów składa się z tysięcy komponentów programowych i sprzętowych oraz użytkowników, którzy podejmują decyzje na podstawie informacji otrzymanej z systemu.

Problemy instrukcji systemów Duże systemy są z reguły przeznaczone do rozwiązywania skomplikowanych zadań. Inżynieria systemowa wymaga dużego wysiłku koordynacyjnego: wzajemne związki pomiędzy komponentami, wymóg zrozumienia innych dziedzin inżynierii. Systemy muszą być trwałe.

Oprogramowanie, a inżynieria systemowa Wzrasta rola oprogramowania np. w powszechnie stosowanych urządzeniach elektronicznych. Ogólnie rzec biorąc problemy inżynierii systemów są podobne do problemów inżynierii oprogramowania. Przez nieporozumienie problem oprogramowania jest spostrzegany jako problem inżynierii systemowej.

Właściwości systemów Systemy charakteryzują się tym, że właściwości i zachowania ich komponentów są nierozerwalnie ze sobą splecione. Poprawne działanie każdego z komponentów systemu zależy od funkcjonowania kilku innych komponentów. Złożone zależności między komponentami systemu oznaczają, że system jest czymś więcej niż tylko sumą swoich części. Te pojawiające się właściwości (Checkland, 1981) nie mogą być przypisane żadnej części systemu.

Przykłady Całkowity ciężar systemu Niezawodność systemu jest przykładem pojawiającej się właściwości, którą można wyznaczyć z właściwości poszczególnych komponentów . Niezawodność systemu zależy od niezawodności komponentów systemu i związków między nimi. Użyteczność systemu jest bardzo złożoną właściwością, która nie zależy jedynie od oprogramowania i sprzętu, ale także od operatorów systemu i środowiska, w którym się go używa .

Typy pojawiających się właściwości systemu Właściwości niefunkcjonalne, takie jak niezawodność, efektywność, bezpieczeństwo i zabezpieczenia. Są związane z zachowaniem systemu w jego środowisku pracy. Często są zasadnicze dla systemów komputerowych, ponieważ niepowodzenie w osiągnięciu pewnego zdefiniowanego minimalnego ich poziomu może sprawić, że system będzie bezużyteczny. Właściwości funkcjonalne, które są widoczne, gdy wszystkie części systemu współpracują, aby osiągnąć pewien cel. Rower ma na przykład cechę funkcjonalną bycia środkiem transportu, gdy scali się go z jego części.

Niezawodność systemu Niezawodność jest złożonym pojęciem, które zawsze należy badać na poziomie systemu, a nie jego poszczególnych komponentów. Komponenty w systemie są od siebie zależne, a zatem awarie w jednym z nich mogą przenosić się na cały system i mieć wpływ na operacje innych systemów. Często projektanci systemu nie są w stanie przewidzieć, jak konsekwencje awarii przenoszą się na cały system Nie mogą zatem podać wiarygodnych oszacowań niezawodności systemu.

Czynniki wpływające na niezawodność całego systemu Niezawodność sprzętu Jakie jest prawdopodobieństwo awarii komponentu sprzętowego i jak długi jest czas jego naprawy? Niezawodność oprogramowania Jakie jest prawdopodobieństwo wytworzenia przez komponent programowy błędnych danych wyjściowych? Awarie oprogramowania istotnie różnią się od awarii sprzętu, ponieważ oprogramowanie nie zużywa się. Niezawodność operatora Jakie jest prawdopodobieństwo błędu operatora systemu?

Zależność czynników niezawodności Awarie sprzętu mogą spowodować wysłanie fałszywych sygnałów, które są poza zakresem danych wejściowych spodziewanych przez oprogramowanie. W takim wypadku oprogramowanie może zachować się w sposób nieprzewidywalny. Błąd operatora jest najbardziej prawdopodobny w sytuacjach stresowych. Dochodzi do tego najczęściej wówczas, gdy system ulega awarii. Błędy operatora mogą mogą mieć wpływ na działanie sprzętu, co prowadzi do dalszych błędów i tak dalej, i tak dalej. Awaria jednego podsystemu, którą można by łatwo naprawić, przeradza się w poważny problem wymagający całkowitego wyłączenia systemu.

Efektywność i użyteczność, bezpieczeństwo i zabezpieczenia Efektywność i użyteczność są trudne do oceny, można je jednak zmierzyć po uruchomieniu systemu. Bezpieczeństwo i zabezpieczenia: mamy tutaj do czynienia nie z atrybutem ogólnego zachowania systemu, ale z zachowania systemu, które nie powinno mieć miejsca. Np. system zabezpieczony to taki, który nie dopuszcza nieuprawnionego dostępu do swoich danych.

Systemy i ich środowiska Systemy nie są niezależnymi bytami, ale istnieją w pewnym środowisku. Środowisko to ma wpływ na funkcjonowanie i efektywność systemu. Czasem środowisko można uważać za system sam w sobie. W ogólniejszym wypadku składa się ono z pewnej liczby oddziałujących na siebie systemów.

Hierarchia systemów Miasto Ulica Budynek System System System wodno- ogrzewania energetyczny kanalizacyjny System System System zsypów zabezpieczeń oświetlenia na śmieci

Ludzkie i organizacyjne czynniki obecne w środowisku systemu Zmiany procesu Czy system wymaga zmian w procesach pracy wykonywanej w środowisku? Zmiany zawodu Czy system zmniejsza umiejętności użytkowników i sprawia, że muszą zmienić swój styl pracy? Zmiany organizacyjne Czy system zmienia strukturę ośrodków władzy politycznej w organizacji?

Modelowanie systemu W trakcie czynności spisywania wymagań i projektowania musi powstać model systemu jako zbioru komponentów i związków między nimi. Architektura systemu jest zwykle prezentowana jako diagram blokowy, obrazujący najważniejsze podsystemy i połączenia między nimi. Każdy podsystem jest rysowany w postaci prostokąta na diagramie blokowym.

Prosty system antywłamaniowy Detektory ruchu Detektory drzwiowe Centralka alarmu Syrena Syntezator mowy Automat dzwoniący Zewnętrzne centrum monitoringu

Komponenty funkcjonalne systemu Komponenty detektorowe zbierają informacje. Komponenty efektorowe (uruchamiające) powodują zmiany w środowisku systemu. Komponenty obliczeniowe wytwarzają wyniki. Komponenty komunikacyjne łącza różne komponenty. Komponenty koordynujące koordynują operacje innych komponentów. Komponenty interfejsu przetwarzają reprezentacje danych.

Przykłady komponentów funkcjonalnych systemu Komponenty detektorowe Zbierają informacje ze środowiska systemu. Przykładami takich komponentów są radary w systemie kontroli lotów, detektory papieru w drukarkach laserowych i termopara w piecu. Komponenty efektorowe (uruchamiające) Powodują zmiany w środowisku systemu. Przykładami takich komponentów są zawory, które otwierają się i zamykają, aby zwiększyć lub zmniejszyć przepływ cieczy w rurze, stateczniki samolotu, które wyznaczają kierunek lotu, i mechanizm wciągania papieru do drukarki, który przesuwa papier za detektor papieru. Komponenty obliczeniowe Pobierają dane wejściowe, wykonują na nich pewne obliczenia i wytwarzają wyniki. Przykładem takiego komponentu jest procesor zmiennopozycyjny, który wykonuje obliczenia na liczbach rzeczywistych.

C.d. przykładów komponentów funkcjonalnych systemu Komponenty komunikacyjne Umożliwiają komunikację innym komponentom systemu. Przykładem takiego komponentu jest sieć łącząca różne komputery wewnątrz budynku. Komponenty koordynujące Koordynują operacje innych komponentów. Np. w układach czasu rzeczywistego jest to komponent szeregujący zadania. Komponenty interfejsu Przetwarzają dane w reprezentacji używanej przez jedne komponenty na reprezentacje używane przez inne komponenty. Przykładem może być komponent interfejsu do komunikacji z człowiekiem, który pobiera pewien model systemu i wyświetla go operatorowi. Innym przykładem jest przetwornik analogowo-cyfrowy, który zamienia wejście analogowe na wyjście cyfrowe.

Charakterystyka procesu inżynierii systemów Interdyscyplinarna zawiłość: wiele różnych dziedzin inżynierii wchodzi w skład inżynierii systemów. Ograniczona możliwość modyfikacji systemu w trakcie jego tworzenia: zmiana raz podjętych decyzji dotyczących systemu często jest bardzo kosztowna, ale wtedy można jeszcze – odpowiadając na nowe wymagania - wykorzystać elastyczność oprogramowania.

Proces inżynierii systemów Definicja wymagań Likwidacja systemu Ewolucja systemu Projektowanie systemu Tworzenie podsystemów Instalacja systemu Integracja systemu

Interdyscyplinarna zawiłość inżynierii systemów Inżynieria oprogramowania Inżynieria elektroniczna Inżynieria mechaniczna Inżynieria strukturalna Inżynieria systemu kontroli lotów Projektowanie interfejsu użytkownika Inżynieria lądowa Inżynieria elektryczna Architektura

Rodzaje wymagań systemowych Trzy rodzaje wymagań: abstrakcyjne wymagania funkcjonalne: podstawowe funkcje, które system ma wypełniać są definiowane na wysokim poziomie abstrakcji; właściwości systemu: są to niefunkcjonalne, pojawiające się właściwości systemu; cechy, których system ma nie mieć: czasem wyspecyfikowanie tego, czego systemowi nie wolno robić, jest tak samo ważne, jak określenie tego, co system powinien robić.

Dwojaki sposób definiowania wymagań systemowych Ważną częścią fazy definicji wymagań jest ustalenie zbioru ogólnych celów, które system ma osiągnąć. (1) Funkcjonalność systemu Dostarczyć antywłamaniowy i przeciwpożarowy system alarmowy biurowca, który na zewnątrz i we wnętrzu wyemituje ostrzeżenie o pożarze lub włamaniu. (2) Cele organizacyjne Zapewnić, aby normalna praca w biurowcu nie była poważnie zakłócona przez pożary i włamania.

Trudność z określaniem wymagań stawianych systemowi Problemy, w których rozwiązaniu mają pomóc budowane złożone systemy są zwykle „problemami złośliwymi” (Rittel i Webber, 1973). „Problem złośliwy” to taki skomplikowany problem, w którym jest tak wiele powiązanych ze sobą bytów, że nie istnieje jego ostateczna specyfikacja. Prawdziwy charakter problemu objawia się dopiero w miarę opracowywania rozwiązania.

Proces projektowania systemu Podziel wymagania Analizuje się i łączy w grupy powiązane ze sobą wymagania. Zwykle istnieje kilka możliwych sposobów podziału. Zidentyfikuj podsystemy Identyfikuje się różne podsystemy, które samodzielnie lub zespołowo spełniają wymagania. Przypisz wymagania podsystemom Przypisuje się wymagania do podsystemów. Teoretycznie powinno to być bardzo proste, o ile do identyfikacji podsystemów użyto grupowania wymagań. Określ funkcjonalność podsystemów Specyfikuje się poszczególne funkcje realizowane przez podsystemy. Zdefiniuj interfejsy podsystemów Definiuje się interfejsy oferowane i wymagane przez poszczególne podsystemy.

Diagram procesu projektowania systemu Podziel wymagania Zdefiniuj interfejsy podsystemów Zidentyfikuj podsystemy Określ funkcjonalność podsystemów Przypisz wymagania podsystemom

Trudności z określaniem wymagań stawianych systemowi Objęcie wymaganiami całego zakresu rozwiązań z rożnymi kombinacjami sprzętu, oprogramowania i pracy ludzkiej. Oczekiwanie, ze system będzie od razu funkcjonował bez zarzutu. Czynniki natury organizacyjnej i politycznej mają istotny wpływ na wybór rozwiązania.

Tworzenie podsystemów W czasie tworzenia podsystemów implementuje się podsystemy zidentyfikowane w trakcie projektowania. Proces tworzenia rzadko będzie polegał na budowie wszystkich podsystemów od zera. Na ogół część podsystemów będzie jednak komercyjnymi systemami z półki (Commercial, Off-The-Shelf, COTS) zakupionymi w celu integracji z naszym systemem. Różne systemy są zwykle tworzone równolegle.

Integracja systemu Z powodów technicznych i menedżerskich najlepiej jest jednak integrować przyrostowo, tzn. w jednym kroku jest integrowany jeden system. Zwykle nie da się ustalić harmonogramów budowania wszystkich podsystemów tak, aby kończyły się w tym samym czasie. Integracja przyrostowa zmniejsza koszty wykrywania błędów. Awarie podsystemów , które są konsekwencjami niewłaściwych założeń o innych podsystemach, są zwykle wykrywane w trakcie integracji systemu.

Problemy instalacji Środowisko, w którym system ma być zainstalowany, jest inne niż to, które zakładali twórcy systemu. Potencjalni użytkownicy systemu mogą być wrogami jego wprowadzenia. Nowy system ma koegzystować z istniejącym systemem do czasu przekonania firmy, że nowy system pracuje poprawnie. Mogą wystąpić fizyczne problemy z instalacją.

Działanie systemu Uruchomienie systemu może wymagać organizacji sesji szkoleniowych dla operatorów i zmiany normalnego toku pracy. Nie wykryte problemy mogą pojawić się w tej fazie, ponieważ specyfikacja systemu mogła zawierać błędy i opuszczenia. Współpraca nowego systemu z istniejącymi już systemami: niekompatybilność, zwiększenie liczby błędów operatora, poprzez mylenie poleceń dostępnych w różnych interfejsach.

Ewolucja systemu Czas życia wielkich złożonych systemów jest bardzo długi. W trakcie swego działania systemy te musza ewoluować. Ewolucja oprogramowania jest ze swej natury kosztowna: proponowane zmiany muszą być bardzo starannie rozważone z punktu widzenia przedsiębiorstwa i technologii, podsystemy nigdy nie są całkowicie niezależne, przyczyny pierwotnych decyzji projektowych zwykle nie są zapisywane, w miarę starzenia się systemu jego struktura staje się coraz bardziej skomplikowana przez zmiany.

Likwidacja systemu Likwidacja systemu oznacza wycofanie go po okresie jego pożytecznego użytkowania. Utylizacja substancji systemu. W wypadku samego oprogramowania, w odróżnieniu od całego systemu, nie ma mowy o żadnych fizycznych problemach z likwidacją.

Zaopatrywanie w system Klientami kupującymi złożone systemy komputerowe są zwykle duże przedsiębiorstwa, np. instytucje wojskowe, rządowe i służby ratownicze. System może być kupiony jako całość, a także jako zestaw oddzielnych części, które potem się integruje, specyficznie projektuje i wytwarza. W wypadku wielkich systemów podjęcie decyzji, którą z tych opcji wybrać, może trwać miesiące, a nawet lata.

Proces zaopatrywania w system Systemy z półki są dostępne Zaadaptuj wymagania Wybierz system Ogłoś przetarg Wybierz dostawcę Zbadaj rynek w poszukiwaniu istniejących systemów Podpisz kontrakt na budowanie Wyślij zapytanie ofertowe Wybierz ofertę Negocjuj kontrakt Wymagany jest system na zamówienie

Problemy zaopatrywania Komponenty z półki zwykle nie spełniają wymagań idealnie, chyba że napisano te wymagania z myślą o tych właśnie komponentach. Gdy system będzie budowany na zamówienie, specyfikacja wymagań jest podstawą kontraktu na zamówienie w system. Po wybraniu wykonawcy systemu następuje okres negocjacji kontraktu, w trakcie którego uzgadnia się dalsze zmiany wymagań i omawia różne sprawy, np. koszt zmian.

Wykonawcy i podwykonawcy Bardzo wiele firm może samodzielnie projektować, tworzyć i przetestować wszystkie komponenty wielkiego złożonego systemu. Wykonawca, którego zwykle nazywamy generalnym, może podpisać kontrakt na zbudowanie rozmaitych podsystemów z pewna liczbą podwykonawców. Takie konsorcjum powinno być zdolne do wykonania wszystkich prac związanych z tym typem systemu.

Model wykonawca - podwykonawca Klient potrzebujący systemu Generalny wykonawca Podwykonawca 2 Podwykonawca 3 Podwykonawca 1

Główne tezy Inżynieria systemów jest złożonym i trudnym procesem, który wymaga wkładu pracy specjalistów wielu dziedzin inżynierii. Pojawiające się właściwości systemu są charakterystykami systemu jako całości, a nie jego części składowych. Architektury systemów zwykle prezentuje się na diagramach blokowych, przedstawiających główne podsystemy i związki między nimi.

Główne tezy c.d. Typami komponentów funkcjonalnych systemu są komponenty detektorowe, komponenty detektorowe, komponenty obliczeniowe, komponenty koordynujące, komponenty komunikacyjne i komponenty interfejsu. Proces inżynierii systemów obejmuje specyfikację, projektowanie, tworzenie, integrację i testowanie. Proces zaopatrywania w system obejmuje specyfikację systemu, ogłoszenie przetargu, wybór dostawcy i zawarcie kontraktu na dostawę systemu.