Inżynieria oprogramowania - 2 Slide 1
Inżynieria systemów
. Projektowanie, implementacja,
rozlokowanie i obsługa systemów
obejmujących sprzęt,
oprogramowanie i ludzi
Inżynieria oprogramowania - 2 Slide 2
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
Inżynieria oprogramowania - 2 Slide 3
Zawartość
. Pojawiające się właściwości systemu
. Systemy i ich środowisko
. Modelowanie systemu
. Proces inżynierii systemów
. Zaopatrywanie w system
Inżynieria oprogramowania - 2 Slide 4
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
Inżynieria oprogramowania - 2 Slide 5
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
Inżynieria oprogramowania - 2 Slide 6
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 (niestety) postrzegane jako
problem inżynierii systemów. Wiele projektów
dużych systemów opóźnia się z powodu problemów
z oprogramowaniem
Inżynieria oprogramowania - 2 Slide 7
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
Inżynieria oprogramowania - 2 Slide 8
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
Inżynieria oprogramowania - 2 Slide 9
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 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 oprogramowania - 2 Slide 10
. 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
Inżynieria niezawodności systemu
Inżynieria oprogramowania - 2 Slide 11
. 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?
Czynniki wpływające na
niezawodność
Inżynieria oprogramowania - 2 Slide 12
Związki 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ść
Inżynieria oprogramowania - 2 Slide 13
Inne właściwości
. Właściwości takie jak efektywność i niezawodność
mogą być zmierzone
. Istnieją właściwości których system nie powinien
eksponować
. 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
Inżynieria oprogramowania - 2 Slide 14
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
Inżynieria oprogramowania - 2 Slide 15
Hierarchia systemów
Miasto
Ulica
Budynek
System
ogrzewania
System
zabezpieczeń
System
energetyczny
System
oświetlenia
System
wodno-
kanalizacyjny
System
usuwania
śmieci
Inżynieria oprogramowania - 2 Slide 16
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?
Inżynieria oprogramowania - 2 Slide 17
Modelowanie architektury systemu
. Model architektury przedstawia abstrakcyjny widok
podsystemów składających się na cały system
. 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
Inżynieria oprogramowania - 2 Slide 18
System antywłamaniowy
Centralka
alarmowa
Syrena Syntezator
mowy
Automat
telefoniczny
Detektory
drzwiowe
Detektory
ruchu
Inżynieria oprogramowania - 2 Slide 19
Typy komponentów w systemie
alarmowym
. Czujnik
. Detektor ruchu, detektory drzwiowe
. Element wykonawczy
. Syrena
. Komunikacja
. Automat telefoniczny
. Koordynacja
. Centralka alarmowa
. Interfejs
. Syntezator mowy
Inżynieria oprogramowania - 2 Slide 20
Architektura
systemu kontroli
lotów
System
radarów
System
transpondera
System
przekazywania
danych
Komunikacja
z samolotem
System
telefoniczny
Procesor
położenia
Procesor
komunikacyjny
Symulacja
samolotu
System map
pogody
System
utrzymania
Baza danych z
planami lotu
System dziennika
czynności
System informacji
dla kontrolera
Konsole
kontrolerów
Zapasowy
procesor
położenia
Zapasowy
procesor
komunikacyjny
Inżynieria oprogramowania - 2 Slide 21
Komponenty funkcjonalne systemu
. Komponenty detektorowe
. Komponenty wykonawcze
. Komponenty obliczeniowe
. Komponenty komunikacyjne
. Komponenty koordynujące
. Komponenty interfejsu
Inżynieria oprogramowania - 2 Slide 22
Komponenty systemu
. Komponenty detektorowe
. Zbierają informacje ze środowiska systemu, np. radary w
systemie kontroli lotów
. Komponenty wykonawcze
. Powodują zmiany w środowisku systemu, np. zawory które
otwierają się i zamykają aby zwiększyć lub zmniejszyć przepływ
cieczy w rurze
. Komponenty obliczeniowe
. Wykonują pewne obliczenia na danych wejściowych i
wytwarzają wyniki, np. procesor zmiennoprzecinkowy w
systemach komputerowych
Inżynieria oprogramowania - 2 Slide 23
Komponenty systemu
. Komponenty komunikacyjne
. Pozwalają komponentom systemowym na komunikację między sobą,
np. sieć łącząca rozproszone komputery
. Komponenty koordynujące
. Koordynują operacje innych komponentów systemu, np. proces
szeregujący w systemach czasu rzeczywistego
. Komponenty interfejsu
. Ułatwiają interakcje pomiędzy komponentami systemu, np. interfejs
operatora (komunikacja z człowiekiem)
. Wszystkie komponenty są zwykle sterowane programowo
Inżynieria oprogramowania - 2 Slide 24
Typy komponentów w systemie
alarmowym
. Czujnik
. Detektor ruchu, detektory drzwiowe
. Komponent uruchamiający
. Syrena
. Komunikacja
. Automat telefoniczny
. Koordynacja
. Centralka alarmowa
. Interfejs
. Syntezator mowy
Inżynieria oprogramowania - 2 Slide 25
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.
Inżynieria oprogramowania - 2 Slide 26
Proces inżynierii systemów
Definicja wymagań
Projektowanie
systemu
Tworzenie
podsystemów
Integracja
systemów
Instalacja
systemu
Ewolucja
systemu
Likwidacja
systemu
Inżynieria oprogramowania - 2 Slide 27
Interdyscyplinarna zawiłość
inżynierii systemów
Inżynieria systemu
kontroli lotów
Inżynieria
oprogramowania
Inżynieria
strukturalna
Inżynieria
lądowa
Inżynieria
mechaniczna
Projektowanie
interfejsu
użytkownika
Architektura
Inżynieria
elektroniczna
Inżynieria
elektryczna
Inżynieria oprogramowania - 2 Slide 28
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
Inżynieria oprogramowania - 2 Slide 29
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
Inżynieria oprogramowania - 2 Slide 30
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
Inżynieria oprogramowania - 2 Slide 31
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 (COTS) może
wyniknąć konieczność zmiany wymagań
. Określenie funkcjonalności podsystemów
. Zdefiniowanie interfejsów podsystemów
. Definiuje się interfejsy poszczególnych podsystemów po czym można równolegle pracować
nad podsystemami
Inżynieria oprogramowania - 2 Slide 32
Proces projektowania systemu
Podziel
wymagania
Zidentyfikuj
podsystemy
Określ
funkcjonalność
podsystemów
Zdefiniuj
interfejsy
podsystemów
Przypisz
wymagania
podsystemom
Inżynieria oprogramowania - 2 Slide 33
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ć
Inżynieria oprogramowania - 2 Slide 34
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)
. Brak komunikacji w zespole implementacyjnym
. Biurokratyczny i powolny mechanizm proponowania zmian
systemu oznacza, że harmonogram prac może zostać
przekroczony
Inżynieria oprogramowania - 2 Slide 35
. Proces łączenia sprzętu, oprogramowania i ludzi w
celu stworzenia systemu
. 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
Integracja systemów
Inżynieria oprogramowania - 2 Slide 36
. Założenia środowiskowe mogą być niewłaściwe
. Potencjalni użytkownicy systemu mogą być
przeciwni jego wprowadzaniu
. Nowy system powinien koegzystować z istniejącym
systemem przez pewien czas
. Mogą wystąpić fizyczne problemy z instalacją (np.
problemy z okablowaniem)
Instalacja systemu
Inżynieria oprogramowania - 2 Slide 37
. Mogą pojawić się nieoczekiwane wymagania
. Użytkownicy mogą używać systemu w sposób nie
przewidziany 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
Działanie systemu
Inżynieria oprogramowania - 2 Slide 38
Ewolucja systemu
. Duże systemy maja długi czas życia. Musza one ewoluować wraz
ze zmieniającymi się wymaganiami
. Ewolucja systemu jest kosztowna
. 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
. Struktura systemu ulega komplikacji w miarę wprowadzania zmian
. Istniejące systemy, które trzeba utrzymywać, nazywane są
czasem systemami odziedziczonymi
Inżynieria oprogramowania - 2 Slide 39
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
Inżynieria oprogramowania - 2 Slide 40
Zaopatrywanie w system
. Nabywany przez organizację system musi spełniać
pewne wymagania
. Niektóre specyfikacje systemu i projekty
architektury opracowuje się przed podjęciem decyzji
zaopatrzeniowych
. Aby móc podpisać kontrakt na budowę systemu należy najpierw
opracować specyfikację tego systemu
. Specyfikacja pozwala na kupno komercyjnego systemu, co jest
tańsze niż tworzenie systemu w oddzielnym przedsięwzięciu
Inżynieria oprogramowania - 2 Slide 41
Proces zaopatrywania w system
Wybierz
dostawcę
Ogłoś
przetarg
Wybierz
system
Zaadaptuj
wymagania
Podpisz kontrakt
na budowę
Negocjuj
kontrakt
Wybierz
ofertę
Wyślij zapytanie
ofertowe
Zbadaj rynek w
poszukiwaniu
istniejących systemów
Dostępne systemy z półki
Wymagany jest system na zamówienie
Inżynieria oprogramowania - 2 Slide 42
Kwestie zaopatrywania
. Wymagania zmieniają się tak by dopasować je do
charakteru komponentów z półki
. Specyfikacja wymagań może być częścią kontraktu
na rozwój systemu
. Po wybraniu wykonawcy systemu następuje okres
negocjacji kontraktu, w trakcie którego uzgadnia się
dalsze zmiany wymagań
Inżynieria oprogramowania - 2 Slide 43
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
Inżynieria oprogramowania - 2 Slide 44
Model wykonawca/podwykonawca
Klient potrzebujący
systemu
Generalny
wykonawca
Podwykonawca 2 Podwykonawca 1 Podwykonawca 3
Inżynieria oprogramowania - 2 Slide 45
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
Inżynieria oprogramowania - 2 Slide 46
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