Inżynieria systemów

Specyfikowanie, projektowanie, implementacja, weryfikowanie, wdrażanie i pielęgnacja systemów.

W kręgu zainteresowań IS pozostaje ponadto: oprogramowanie, sprzęt, oraz interakcja systemu z użytkownikami i środowiskiem. IS postrzega system jako całość.

Inżynierowie oprogramowania muszą rozumieć inżynierię systemów, ponieważ problemy inżynierii oprogramowania są często rezultatem decyzji inżynierów systemów.

Cele

• Wyjaśnienie, dlaczego oprogramowanie systemu pozostaje pod wpływem ogólniejszych zagadnień inżynierii systemów

• Wprowadzenie w pojęcia pojawiających się właściwości systemu takich jak niezawodność i bezpieczeństwo

• Wyjaśnienie, dlaczego środowisko systemu musi być rozważane w procesie projektowania systemu

• Wyjaśnienie inżynierii systemów i procesów zaopatrywania w system

Zawartość

• Pojawiające się właściwości systemu

• Systemy i ich środowisko

• Modelowanie systemu

• Proces inżynierii systemów

• Zaopatrywanie w system

Co to jest system?

Celowa kolekcja powiązanych ze sobą komponentów współpracujących razem aby osiągnąć pewien wspólny cel

• System może zawierać oprogramowanie oraz sprzęt mechaniczny, elektryczny i elektroniczny obsługiwany przez ludzi

• Komponenty systemu są zależne od innych komponentów systemu

• Właściwości i zachowanie komponentów systemu są nierozerwalnie ze sobą splecione

Problemy inżynierii systemów

• Duże systemy zwykle projektowane są w celu rozwiązania „złośliwych” problemów

• Inżynieria systemów wymaga powiązań wielu dziedzin

• Prawie nieskończona liczba możliwości doboru elementów systemu

• Wzajemna nieufność i brak zrozumienia pomiędzy inżynierami różnych dziedzin

• Systemy muszą być projektowane z uwzględnieniem zmieniającego się środowiska

Oprogramowanie i inżynieria systemów

• Proporcja udziału oprogramowania w systemach ma tendencję wzrostową

• Problemy inżynierii systemów są podobne do problemów inżynierii oprogramowania

• Oprogramowanie jest postrzegane jako problem inżynierii systemów.

• Wiele projektów dużych systemów opóźnia się z powodu problemów z oprogramowaniem

Pojawiające się właściwości

• Właściwości systemu to właściwości systemu jako całości a nie wynikające z właściwości poszczególnych komponentów systemu

• Pojawiające się właściwości są konsekwencją związków pomiędzy komponentami systemu

• Mogą być oszacowane i zmierzone tylko wtedy, gdy podsystemy są już zintegrowane i tworzą kompletny system

Przykłady pojawiających się właściwości

• Całkowity ciężar systemu

Przykład 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 to złożona właściwość, 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

• Właściwości funkcjonalne

Objawiają się, kiedy wszystkie części systemu pracują razem aby osiągnąć pewien cel. Przykładowo, rower ma cechę funkcjonalną bycia środkiem transportu, gdy scali się go z jego części

• Właściwości niefunkcjonalne

Przykładem są niezawodność, efektywność czy bezpieczeństwo. 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

Inżynieria niezawodności systemu

• Z powodu wspólnej zależności komponentów systemu błąd może propagować się przez cały system

• Błędy systemu często zdarzają się z powodu nieoczekiwanych powiązań pomiędzy komponentami

• Jest niemal niemożliwe przewidzieć wszystkie możliwe powiązania pomiędzy komponentami

• Miary niezawodności oprogramowania mogą dać fałszywy obraz niezawodności systemu

Czynniki wpływające na niezawodność

• Niezawodność sprzętu

• Jakie jest prawdopodobieństwo awarii sprzętu 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 tym, iż oprogramowanie nie zużywa się

• Niezawodność operatora

• Jakie jest prawdopodobieństwo, że operator systemu popełni błąd?

Związki między czynnikami niezawodności

• Awarie sprzętu mogą generować fałszywe sygnały, które są poza zakresem danych wejściowych spodziewanych przez oprogramowanie

• Błędy oprogramowania mogą być przyczyną alarmów powodujących sytuacje stresowe dla operatorów. W takich sytuacjach operator najczęściej popełnia błędy

• Środowisko, w którym system jest zainstalowany może wpływać na jego niezawodność

Inne właściwości

• Właściwości takie jak efektywność i niezawodność są trudne do oceny. Mogą być zmierzone po uruchomieniu systemu.

• Istnieją właściwości, których system nie powinien wykazywać

• Bezpieczeństwo - system nie powinien zachowywać się w sposób niebezpieczny

• Stopień zabezpieczenia - system nie powinien zezwalać na nieuprawnione użycie

• Pomiar i oszacowanie tych własności jest bardzo trudne

Systemy i ich środowisko

• Systemy nie są niezależne, lecz istnieją w środowisku

• Systemy mogą powodować zmiany w swoim środowisku

• Środowisko wpływa na funkcjonowanie systemu, np system może wymagać elektrycznego zasilania ze swojego środowiska

• Ważne jest zarówno środowisko organizacyjne jak i fizyczne

Hierarchia systemów

Czynniki ludzkie i organizacyjne

• 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ą zmieniać swój styl pracy?

• Zmiany organizacyjne

• Czy system zmienia strukturę ośrodków władzy politycznej w organizacji?

Modelowanie architektury systemu

• Model architektury przedstawia abstrakcyjny zbiór podsystemów składających się na cały system oraz związków między nimi

• Może on zawierać schemat podstawowego przepływu informacji pomiędzy poszczególnymi podsystemami

• Zwykle prezentowany jest jako diagram blokowy

• Może identyfikować różne typy funkcjonalnych komponentów w modelu

System antywłamaniowy

Detektory ruchu Wykrywają ruch w monitorowanych pomieszczeniach. (Detektor)

Detektory drzwiowe Wykrywają otwarcie zewnętrznych drzwi budynku. (Detektor)

Centralka alarmu Steruje działaniem systemu. (Koordynator)

Syrena Nadaje sygnały dźwiękowe po wykryciu intruza. (Efektor)

Syntezator mowy Nadaje słowny komunikat informujący o położeniu intruza. (Interfejs)

Automat dzwoniący Wykonuje zewnętrzne połączenie telefoniczne do firmy ochroniarskiej i policji. (Komunikator)

Typy komponentów w systemie alarmowym

• Komponenty detektorowe zbierają informacje ze środowiska systemu.

• Komponenty efektorowe (uruchamiające) powodują zmiany w środowisku systemu.

• Komponenty obliczeniowe pobierają dane wejściowe, wykonują na nich pewne obliczenia i wytwarzają wyniki.

• Komponenty komunikacyjne umożliwiają komunikację innym komponentom systemu.

• Komponenty koordynujące koordynują operacje innych komponentów.

• Komponenty interfejsu przetwarzają dane w reprezentacji używanej przez jedne komponenty na reprezentacje używane przez inne komponenty.

Proces inżynierii systemów

• Zwykle stosowany model kaskadowy (ang. waterfall) z powodu potrzeby równoległego rozwoju różnych części systemu

• Mała możliwość iteracji pomiędzy fazami, ponieważ zmiany sprzętu są bardzo kosztowne. Problemy sprzętowe muszą być kompensowane poprzez oprogramowanie.

• Konieczność angażowania inżynierów różnych dyscyplin, którzy muszą pracować razem

• Duża skala nieporozumień. Różne dyscypliny posługują się różnym słownictwem, co wymaga wielu negocjacji.

Proces inżynierii systemów

Interdyscyplinarna zawiłość inżynierii systemów

Definicja wymagań systemowych

• W tej fazie definiuje się trzy typy wymagań

• Abstrakcyjne wymagania funkcjonalne - funkcje systemu definiowane są na wysokim poziomie abstrakcji

• Właściwości systemu - definiowane są niefunkcjonalne wymagania systemu

• Cechy niepożądane - specyfikacje nieakceptowalnych zachowań systemu

• Powinna również obejmować ogólne cele organizacyjne systemu

Cele systemów

• Cele funkcjonalne

• Dostarczenie antywłamaniowego i przeciwpożarowego systemu dla budynku, który na zewnątrz i wewnątrz wyemituje ostrzeżenie o pożarze lub włamaniu

• Cele organizacyjne

• Zapewnić aby normalna praca w biurowcu nie była poważnie zakłócana przez pożary i włamania

Problemy z określaniem wymagań

• Zmiany, kiedy system jest już określony

• Trzeba przewidywać rozwój sprzętu/komunikacji podczas czasu życia systemu

• Trudno zdefiniować wymagania niefunkcjonalne, w szczególności takie, które nie znajdują odbicia w strukturze systemu

Proces projektowania systemu

• Podział wymagań - Organizacja wymagań w grupy powiązane ze sobą

• Identyfikacja podsystemów -Identyfikacja zbioru podsystemów, które zespołowo spełniają wymagania systemu

• Przydzielenie wymagań podsystemom - Przypisanie podsystemom wymagań. Z ograniczeń narzuconych przez zakupione na zewnątrz podsystemy może wyniknąć konieczność zmiany wymagań

• Określenie funkcjonalności podsystemów - specyfikacja poszczególnych funkcji realizowanych przez podsystemy

• Zdefiniowanie interfejsów podsystemów - Definiuje się interfejsy poszczególnych podsystemów, po czym można równolegle pracować nad podsystemami

Proces projektowania systemu

Dwukierunkowe strzałki na rysunku oznaczają, że między każdą parą kroków procesu projektowania występuje wiele iteracji i sprzężeń zwrotnych

Problemy podczas projektowania systemu

• Podział zadań pomiędzy komponenty sprzętowy, programowy i ludzki może wymagać wielu negocjacji

• Przypuszcza się, że trudne problemy projektowe zostaną rozwiązane przy użyciu oprogramowania

• Platformy sprzętowe mogą być niewłaściwe dla wymagań oprogramowania, więc oprogramowanie musi to kompensować

Tworzenie podsystemów

• Typowo w projekcie rozwija się komponenty sprzętowe, programowe i komunikację pomiędzy nimi

• Mogą zawierać produkty „z półki” - COTS (Commercial Off-the-Shelf) - zakupione w celu integracji z tworzonym systemem

• Brak komunikacji w zespole implementacyjnym

• Biurokratyczny i powolny mechanizm proponowania zmian systemu oznacza, że harmonogram prac może zostać przekroczony

Integracja systemów

Integracja systemu polega na pobraniu niezależnie zbudowanych podsystemów i scaleniu ich w jeden kompletny system.

• Integracja powinna być przyrostowa, tzn. w jednym kroku powinien być integrowany jeden podsystem

• Na tym etapie wynikają problemy związane z interfejsami pomiędzy podsystemami

• Problemy może wystąpić przy nieskoordynowanym dostarczaniu komponentów systemu

Instalacja systemu

Umieszczanie systemu w środowisku, w którym ma działać

Problemy:

• Założenia środowiskowe mogą być niewłaściwe.

• Potencjalni użytkownicy systemu mogą być przeciwni jego wprowadzaniu. (np zmniejszenie liczby stanowisk w firmie).

• Nowy system powinien koegzystować z istniejącym systemem przez pewien czas.

• Mogą wystąpić fizyczne problemy z instalacją (np problemy z okablowaniem).

Działanie systemu

Liczone od momentu zainstalowania systemu.

Problemy:

• Mogą pojawić się nieoczekiwane wymagania

• Użytkownicy mogą używać systemu w sposób nieprzewidziany przez projektantów

• Mogą pojawić się problemy ze współpracą z innymi systemami

• Problem niekompatybilności

• Problemy z konwersją danych

• Wzrost liczby błędów popełnianych przez operatorów z powodu różnicy w interfejsach użytkownika

Ewolucja systemu

• Duże systemy mają długi czas życia. Muszą one ewoluować wraz ze zmieniającymi się wymaganiami

• Ewolucja systemu jest kosztowna z następujących powodów:

• Zmiany muszą być przeanalizowane z technicznego i biznesowego punktu widzenia

• Podsystemy współpracują ze sobą, więc mogą pojawić się nieprzewidziane problemy

• Rzadko zapisywane są przyczyny pierwotnych decyzji projektowych stąd osoby zajmujące się ewolucją muszą ustalać, dlaczego podjęto takie decyzje

• Struktura systemu ulega komplikacji w miarę wprowadzania zmian

• Istniejące systemy, które trzeba utrzymywać, nazywane są czasem systemami odziedziczonymi

Likwidacja systemu

Wycofanie systemu z użycia po okresie jego pożytecznego użytkowania

• Może wymagać usunięcia materiałów (Np. niebezpiecznych chemikaliów), które mogą zanieczyszczać środowisko

• Może być wymagana restrukturyzacja i konwersja danych do postaci możliwej do używania w innym systemie

Zaopatrywanie w system

Proces zaopatrywania w system polega na podejmowaniu decyzji o najlepszych sposobach zdobycia systemu i wybraniu najlepszych jego dostawców.

Proces zaopatrywania jest ściśle związany z procesem inżynierii systemów. Niektóre specyfikacje systemu i projekty architektury opracowuje się przed podjęciem decyzji zaopatrzeniowych. Istnieją dwie przyczyny takiej kolejności działań:

• Aby kupić lub podpisać kontrakt na projekt i budowę systemu, należy najpierw na wysokim poziomie abstrakcji opracować specyfikację tego, co system ma robić.

• Niemal zawsze taniej jest kupić system, niż go zaprojektować, wyprodukować i zbudować jako oddzielne przedsięwzięcie. Pewien zakres projektowania architektonicznego jest konieczny, aby rozpoznać podsystemy, które można kupić, a nie samodzielnie projektować i produkować.

Proces zaopatrywania w system

Dostępne systemy z półki

Wymagany jest system na zamówienie

Kwestie zaopatrywania

• Wymagania zmieniają się tak by dopasować je do charakteru komponentów z półki. Komponenty z półki zwykle nie spełniają wymagań idealnie, chyba, że napi­sano 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 zaopatrzenie w system. Jest to, więc dokument zarówno prawniczy, jak i techniczny.

• Po wybraniu wykonawcy systemu następuje okres negocjacji kontraktu, w trakcie, którego uzgadnia się dalsze zmiany wymagań oraz inne sprawy np. koszt zmian

Wykonawcy i podwykonawcy

• Dostarczanie wielkich sprzętowo-programowych systemów zwykle bazuje na kilku głównych wykonawcach

• Podwykonawcy są angażowani jako wsparcie części systemu

• Klient kontaktuje się z głównym wykonawcą i nie ma bezpośredniego kontaktu z podwykonawcami

Model wykonawca/podwykonawca

Główne tezy

• Inżynieria systemów wymaga wkładu pracy specjalistów różnych dziedzin

• Pojawiające się właściwości systemu są charakterystykami systemu jako całości a nie jego części składowych

• Modele architektury systemów pokazują głównie podsystemy i związki między nimi. Zwykle opisywane są przy użyciu diagramów blokowych

Główne tezy

• Typami komponentów systemu są detektory, komponenty wykonawcze, obliczeniowe, koordynujące, komponenty komunikacyjne i komponenty interfejsu

• Proces inżynierii systemów jest zwykle kaskadowy i obejmuje specyfikację, projektowanie, tworzenie i integrację

• Proces zaopatrywania w system skupia się na podejmowaniu decyzji, który system kupić i od kogo

8

Wykład 2

Budynek

Komunikacja

z samolotem

System

telefoniczny

System

Przekaz. danych

System

transpondera

Zapasowy procesor położenia

Procesor położenia

System

radarów

Zapasowy procesor położenia

Procesor położenia

Symulacja samolotu

System

Map i pogody

System

Dziennika czynności

Konsole kontrolerów

System informacji dla kontrolera

System

księgowy

Baza danych z planami lotu

Inżynieria oprogramowania

Inżynieria elektroniczna

Inżynieria mechaniczna

Architektura

Inżynieria elektryczna

Inżynieria lądowa

Projektowanie interfejsu użytkownika

Inżynieria systemów kontroli lotów

Inżynieria strukturalna

System ogrzewania

System energetyczny

System wodno-kanalizacyjny

System zsypów na śmieci

System oświetlenia

System zabezpieczeń

Ulica

Detektory ruchu

Klient potrzebujący systemu

Zdefiniuj interfejsy podsystemów

Określ funkcjonalność podsystemów

Przypisz wymagania podsystemom

Zidentyfikuj podsystemy

Podziel wymagania

Miasto

Detektory drzwiowe

Centralka alarmowa

Syrena

Syntezator mowy

Automat dzwoniący

---