Inżynieria systemów

komputerowych

Źródło: Ian Sommerville; "Inżynieria oprogramowania"; WNT W-wa 2003

Cele
Celem jest przedstawienie pojęcia inżynierii systemów komputerowych i

wyjaśnienie, dlaczego znajomość inżynierii systemów jest potrzebna inżynierom
oprogramowania. Po przeczytaniu tego rozdziału będziesz:



wiedzieć, dlaczego oprogramowanie w systemie pozostaje pod

wpływem ogólniejszych zagadnień inżynierii systemów;



wprowadzony 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

Inżynieria systemów to czynność specyfikowania, projektowania, implementowania,
weryfikowania, wdrażania i pielęgnacji systemów postrzegana jako całość.
Inżynierowie systemów nie zajmują się tylko oprogramowaniem, ale także sprzętem
komputerowym oraz interakcjami systemu z jego użytkownikami i środowiskiem.
Muszą myśleć o usługach, które system oferuje, ograniczeniach, w ramach których
system musi być zbudowany i w których musi działać, oraz jego interakcji ze
środowiskiem. Inżynierowie oprogramowania muszą rozumieć inżynierię systemów,

ponieważ problemy inżynierii oprogramowania są często wynikiem decyzji inżynierów
systemów.

Jest wiele możliwości zdefiniowania systemu od najbardziej abstrakcyjnych do

konkretnych. Przyjmiemy następującą roboczą definicję:

System jest celową kolekcją powiązanych ze sobą komponentów, które

współpracują, aby osiągnąć pewien cel.

Ta ogólna definicja obejmuje rozmaitość systemów. 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.

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. Oprogramowanie
może działać jedynie wówczas, gdy poprawnie pracuje procesor. Procesor może
prowadzić obliczenia pod warunkiem, że dobrze zainstalowano system
oprogramowania, który definiuje te obliczenia.

Systemy są często hierarchiczne w tym sensie, że zawierają inne systemy.

Policyjny system nadzoru i kierowania może na przykład zawierać system informacji
geograficznej do pobierania szczegółów miejsc incydentów. Te inne systemy noszą
nazwę podsystemów. Podsystemy charakteryzują się tym, że mogą działać jako
niezależne systemy rządzące się swoimi prawami. Ten sam system informacji
geograficznej może być zatem używany w innych systemach. Jego zachowanie w
ramach konkretnego systemu zależy jednak od związków z innymi podsystemami.

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. Pojawiają się
jedynie wówczas, gdy rozpatrujemy system jako całość. Niektóre z tych właściwości
można wyprowadzić bezpośrednio z porównywalnych właściwości podsystemów.
Najczęściej są one jednak wynikiem złożonych wzajemnych zależności

podsystemów, których praktycznie nie da się zrozumieć, analizując poszczególne
komponenty systemu.

Oto niektóre przykłady pojawiających się właściwości systemu:



Całkowity ciężar 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.

W tej książce skoncentrowałem się na systemach komputerowych

zawierających sprzęt i oprogramowanie i oferujących użytkownikom interfejs
zaimplementowany przez oprogramowanie. Inżynierowie oprogramowania powinni
znać podstawy inżynierii systemów komputerowych (Computer-Based System
Engineering, CBSE) (White i inni, 1993) ze względu na znaczenie oprogramowania w
tych systemach. W programie kosmicznym Apollo, dzięki któremu człowiek stanął na
Księżycu w 1969, wykorzystano jedynie 10 megabajtów oprogramowania. Około 100
megabajtów oprogramowania pojawiło się za to w amerykańskim programie stacji
kosmicznej. Inżynieria oprogramowania ma zatem rozstrzygające znaczenie dla
tworzenia z powodzeniem złożonych systemów komputerowych.

2.1. Pojawiające się właściwości systemu
We wprowadzeniu do tego rozdziału wyjaśniłem, że pojawiające się właściwości

systemu są atrybutami systemu jako całości. Zwykle nie jest łatwo z góry przewidzieć
wartości tych właściwości. Można je zmierzyć dopiero wówczas, gdy podsystemy są
już zintegrowane i tworzą kompletny system. Istnieją dwa typy pojawiających się
właściwości:



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.



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.
Niektóre funkcje systemu mogą nie być potrzebne wszystkim jego
użytkownikom, a zatem system można bez tych funkcji zaakceptować.
System, który jest jednak zawodny lub zbyt wolny, będzie prawdopodobnie
odrzucony przez wszystkich użytkowników.

Aby zilustrować złożoność zagadnienia pojawiających się właściwości,

rozważmy na przykład 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 składowych. 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 na podstawie danych o
niezawodności jego składowych.

Istnieją trzy silnie ze sobą powiązane 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ę. Może dalej działać nawet wówczas, gdy
wytworzyło niepoprawny wynik.



Niezawodność operatora. Jakie jest prawdopodobieństwo błędu operatora
systemu?

Wszystkie te czynniki są ze sobą ściśle powiązane. 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ą mieć wpływ na działanie
sprzętu, co prowadzi do dalszych błędów i tak dalej, i tak dalej. Może się zatem
zdarzyć, że awaria jednego podsystemu, którą można by łatwo naprawić, przeradza
się w poważny problem wymagający całkowitego wyłączenia systemu.

Rzeczywista niezawodność zależy od kontekstu, w którym system jest

użytkowany. Wyjaśniłem już wcześniej, że środowiska systemu nie da się z góry
wyspecyfikować. Projektanci nie mogą też ograniczać środowiska działania systemu.
Różne systemy mogą w środowisku niespodziewanie reagować na problemy, co ma
wpływ na niezawodność tych systemów. Nawet wówczas, gdy system już
zintegrowano, nie można podać dokładnych miar jego niezawodności.

Wyobraźmy sobie na przykład system zaprojektowany do pracy w temperaturze

pokojowej. Aby uniknąć odmienności i wyjątkowych warunków, elektroniczne
składniki systemu należy przygotować do działania w innym zakresie temperatur, np.
od 0 do 45 stopni. W innych temperaturach komponenty mogą zachowywać się
nieprzewidywalnie. Załóżmy teraz, że ten system zainstalowano w pobliżu
klimatyzatora. Jeśli klimatyzator ulegnie awarii i wyrzuci gorące powietrze na składniki
elektroniczne naszego systemu, to system może zepsuć się.

Jeśli zainstalowano by ten system w jakimś innym miejscu, nie byłoby

problemów. Jeśli klimatyzator działałby poprawnie, to nie byłoby kłopotów. Z powodu
fizycznej bliskości tych urządzeń zaszedł zatem między nimi niespodziewany
związek, który spowodował awarię systemu.

Podobnie jak niezawodność, inne pojawiające się właściwości, takie jak

efektywność i użyteczność są trudne do oceny, można je jednak zmierzyć po
uruchomieniu systemu. Z właściwościami takimi jak bezpieczeństwo i zabezpieczenia
są związane inne problemy. W tym wypadku mamy po prostu do czynienia nie z
atrybutem ogólnego zachowania systemu, ale zachowania systemu, które nie
powinno mieć miejsca. System zabezpieczony to taki, który nie dopuszcza

nieuprawnionego dostępu do swoich danych. Nie da się przewidzieć wszystkich
sposobów dostępu i jawnie ich zabronić. Można zatem jedynie ocenić te właściwości
przez domniemanie, tzn. system jest niezabezpieczony, gdy komuś udało się do
niego włamać.

2.2. 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, ale w ogólniejszym wypadku
składa się ono z pewnej liczby oddziałujących na siebie systemów.

Na rysunku 2.1 przedstawiono systemy, które mogą być elementami biurowca.

System ogrzewania, system energetyczny, system oświetlenia, system
wodnokanalizacyjny, system zsypów na śmieci i system zabezpieczeń są
podsystemami w ramach budynku, który sam w sobie także jest systemem. Biurowiec
stoi przy ulicy, a ulica leży w mieście itd. Lokalne środowisko systemu to systemy na
tym samym poziomie. Całe środowisko składa się ze środowiska lokalnego i
środowiska systemu otaczającego.

Rys 2.1 Hierarchia systemów

Rozważmy system zabezpieczeń przedstawiony w lewym dolnym rogu

Lokalnym środowiskiem tego systemu są inne systemy wewnątrz budynku. Całe
środowisko zawiera także wszystkie inne systemy na zewnątrz budynku na ulicy i w
mieście oraz systemy naturalne, na przykład system pogodowy.

Istnieją dwa istotne powody, dlaczego inżynierowie systemu muszą znać

otoczenie systemu:

1. W wielu wypadkach system ma powodować pewne zmiany w swoim

środowisku. System ogrzewania zmienia zatem swoje środowisko przez
zwiększanie lub zmniejszanie temperatury. Poprawne działanie systemu
można więc ocenić jedynie na podstawie jego wpływu na środowisko.

2. Na funkcjonowanie systemu mogą mieć wpływ trudne do przewidzenia

zmiany zachodzące w środowisku. Na system instalacji elektrycznej
mogą na przykład oddziaływać zmiany w otoczeniu budynku. Efektem
prac ziemnych może być przerwanie linii zasilającej i wyłączenie systemu
elektrycznego. Burza z piorunami może indukować prądy w instalacji
elektrycznej, które wpływają na normalne funkcjonowanie tego systemu.

Systemy są umieszczone nie tylko w środowisku fizycznym, ale także w

środowisku organizacyjnym. Obejmuje ono strategie i procedury, które również są
regulowane przez ważniejsze od nich zagadnienia polityczne, ekonomiczne,
społeczne i środowiskowe. Jeśli środowisko organizacyjne nie jest dobrze
rozpoznane, to systemy mogą nie spełniać potrzeb przedsiębiorstwa i mogą być
odrzucone przez użytkowników i zarządzających przedsiębiorstwami.

Oto niektóre ludzkie i organizacyjne czynniki obecne w środowisku systemu,

które mają wpływ na projekt systemu:

1. Zmiany procesu. Czy system wymaga zmian w procesach pracy

wykonywanej w środowisku? Jeśli tak, to będą potrzebne szkolenia. Jeśli
zmiany są poważne lub oznaczają utratę pracy przez pewne osoby, to
istnieje niebezpieczeństwo sprzeciwu użytkowników wobec systemu.

2. Zmiany zawodu. Czy system zmniejsza umiejętności użytkowników i

sprawia, że muszą zmienić swój styl pracy? Jeśli tak, mogą oni aktywnie
sabotować wprowadzenie systemu do organizacji. Projekty, które
zmuszają zarządzających do zmiany sposobu pracy tak, aby dostosować

się do systemu komputerowego, bardzo często nie są akceptowane.
Menedżerowie mogą odczuwać, że systemy umniejszyły ich rolę w firmie.

3. Zmiany organizacyjne. Czy system zmienia strukturę ośrodków władzy

politycznej w organizacji? Jeśli firma zależy, na przykład, od złożonego
systemu, to osoby, które wiedzą, jak się nim posługiwać, mają większą
władzę polityczną.

Te ludzkie, społeczne i organizacyjne czynniki są zwykle zasadnicze przy

ocenie, czy system dobrze spełnia swoje funkcje. Niestety, ocena ich wpływu na
system jest bardzo trudna dla inżynierów, którzy zwykle mają bardzo małe
doświadczenie w dziedzinie socjologii i kultury. Aby pomóc w zrozumieniu wpływu
systemu na organizacje, opracowano różne metodyki, takie jak socjo-technika
Mumforda (Mumford, 1989) i Soft System Methodology Checklanda (Checkland,
1981; Checkland i Scholes, 1990). Przeprowadzono też staranne studia socjologiczne
nad skutkami pracy systemów komputerowych.

W idealnej sytuacji cała istotna wiedza o środowisku powinna być częścią

specyfikacji systemu, aby mogli ją wziąć pod uwagę projektanci. W rzeczywistości nie
jest to możliwe. Projektanci muszą przyjmować założenia o środowisku na podstawie
porównywalnych systemów i zdrowego rozsądku. Jeśli pomylą się, to system może
funkcjonować źle w zupełnie nieprzewidywalny sposób.

Jeśli projektanci nie rozumieją na przykład pojęcia zgodności

elektromagnetycznej, to system może działać niepoprawnie w pobliżu urządzeń
emitujących fale elektromagnetyczne.

2.3. 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. Zwykle jest on
przedstawiany graficznie jako model architektury systemu, który daje czytelnikowi
przegląd organizacji systemu.

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. Związki między
podsystemami są zaznaczane za pomocą strzałek łączących prostokąty. Te związki

mogą obejmować przepływy danych, relacje „używa" - „jest używany" lub inne rodzaje
zależności.

Zilustrowano to na rysunku 2.2, na którym przedstawiono dekompozycję

alarmowego systemu anty włamaniowego na jego podstawowe komponenty. Diagram
blokowy powinien być opatrzony krótkimi opisami każdego podsystemu takimi jak na
przykład na rys. 2.3.

Na tym poziomie szczegółowości system podzielono na podsystemy. Każdy

podsystem można przedstawiać w ten sam sposób, dopóki dekomponujemy system
na komponenty funkcjonalne. Komponenty funkcjonalne są to komponenty, które z
punktu widzenia podsystemu realizują jedną funkcję. Podsystemy są zwykle
wielofunkcyjne. Są także możliwe inne spojrzenia (np. wytwórcy komponentów), w
których komponenty są same w sobie systemami.

Dawniej model architektury systemu był używany do zidentyfikowania

komponentów programowych i sprzętowych, które można tworzyć równolegle. To
rozróżnienie sprzętu i oprogramowania staje się jednak nieistotne. Niemal wszystkie
współczesne komponenty mają pewną moc obliczeniową. Maszyny łączące sieci
będą na przykład składać się z fizycznych przewodów oraz wzmacniaków

Rysunek 2.2 Prosty system antywłamaniowy

Podsystem

Opis

Detektory ruchu

Wykrywają ruch w monitorowanych pomieszczeniach

Detektory drzwiowe

Wykrywają otwarcie zewnętrznych drzwi budynku

Centralka alarmu

Steruje działaniem systemu

Syrena

Nadaje sygnały dźwiękowe po wykryciu intruza

Syntezator mowy

Nadaje słowny komunikat informujący o położeniu intruza

Automat dzwoniący

Wykonuje zewnętrzne połączenie telefoniczne do firmy

ochroniarskiej i policji

Rysunek 2.3 Funkcjonalność podsystemów systemu antywłamaniowego

i ruterów sieciowych. Wewnątrz wzmacniaków i ruterów można znaleźć

procesory i oprogramowanie nimi sterujące, a także wyspecjalizowane komponenty
elektroniczne.

Obecnie na poziomie architektury lepiej jest klasyfikować podsystemy względem

ich funkcji, zanim przystąpi się do rozstrzygnięcia dylematów „sprzęt czy
oprogramowanie?". Decyzja, czy konkretną funkcję należy zrealizować za pomocą
sprzętu czy oprogramowania, może wynikać z nietechnicznych przesłanek, na
przykład dostępność komponentów COTS, lub ograniczeń na czas tworzenia
komponentu.

Diagramy blokowe nadają się do systemów dowolnych rozmiarów. Na rysunku

przedstawiono architekturę znacznie większego systemu do kontroli lotów. Składa się
nań kilka głównych podsystemów, które już same w sobie są dużymi systemami.
Przepływ informacji między tymi podsystemami zobrazowano za pomocą łączących je
strzałek.

2.3.1. Komponenty funkcjonalne systemu
Architektura systemu powinna być zaprojektowana w kategoriach

funkcjonalnych podsystemów bez względu na to, czy są to systemy programowe czy
sprzętowe. Komponenty funkcjonalne systemu można raczej zaklasyfikować do
jednej z poniższych kategorii:

Rys.2.4 Architektura systemu kontroli lotów

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.



Komponenty komunikacyjne umożliwiają komunikację innym
komponentom systemu. Przykładem takiego komponentu jest sieć
Ethernet łącząca różne komputery wewnątrz budynku.



Komponenty koordynujące koordynują operacje innych komponentów.
Przykładem takiego komponentu jest proces szeregujący w systemach
czasu rzeczywistego, który decyduje, kiedy poszczególne procesy
powinny mieć przydzielony procesor.



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.

Na rysunku 2.5 wyjaśniono, które z funkcjonalnych typów komponentów

występują w architekturze systemu antywłamaniowego z rys. 2.2.

Podział na różne typy komponentów nie jest ani jednoznaczny, ani

natychmiastowy. W systemach, którymi zapewne będą zajmować się inżynierowie

Typ komponentu

Komponenty

Funkcja

Detektor

Detektor ruchu, detektor
drzwiowy

Wykrywa ruch w monitorowanej
przestrzeni, wykrywa otwarcie
monitorowanych drzwi

Efektor

Syrena

Dźwiękowy sygnał włamania

Komunikacja

Automat dzwoniący

Dzwoni do zewnętrznego centrum
monitoringu i informuje o włamaniu.
Odbiera polecenia z tego centrum

Koordynacja

Centralka alarmu

Koordynuje pracę wszystkich
komponentów systemu. Wykonuje
polecenia otrzymane z klawiatury i
centrum monitoringu

Interfejs

Syntezator mowy

Syntetyzuje komunikat informujący o
położeniu włamywacza

Rysunek 2.5 Typy komponentów systemu antywłamaniowego

oprogramowania, większość komponentów będzie miała wbudowane

oprogramowanie. Oprogramowanie będzie zwykle służyło do sterowania całym
systemem.

Te klasyfikacje komponentów są bardzo pomocne w trakcie projektowania

systemu. Większość systemów zawiera wszystkie rodzaje komponentów.
Powinniśmy jawnie zidentyfikować każdy typ na podstawie wymagań. Jeśli brakuje co
najmniej jednego typu komponentu, prawdopodobnie pominęliśmy coś ważnego w
swoim projekcie.

2.4. Proces inżynierii systemów

Fazy procesu inżynierii systemów są przedstawione na rys. 2.6. Ten proces miał

duży wpływ na model kaskadowy tworzenia oprogramowania.

Istnieją istotne różnice między procesem inżynierii systemów a procesem

tworzenia oprogramowania:

Interdyscyplinarna zawiłość. Wiele różnych dziedzin inżynierii wchodzi w skład

inżynierii systemów. Liczba możliwych nieporozumień jest ogromna, ponieważ dla
różnych dziedzin inżynierii posługujemy się odmienną terminologią.

Ograniczona możliwość modyfikacji w trakcie tworzenia systemu. Gdy pewne

decyzje techniczne (np. umiejscowienie radarów systemu kontroli lotów) są już
podjęte, zmienianie ich jest bardzo kosztowne. Przekształcenie projektu systemu tak,
aby rozwiązać takie problemy, jest możliwe bardzo rzadko. Jedną z przyczyn
znaczenia oprogramowania w systemach jest jego elastyczność - można dokonywać
zmian w odpowiedzi na nowe wymagania.

Rysunek 2.6 Proces inżynierii systemów

Inżynieria systemów jest dziedziną interdyscyplinarną, w której biorą udział

zespoły wyspecjalizowane w rozmaitych dziedzinach. Zespoły te są niezbędne,
ponieważ do oceny konsekwencji decyzji projektowych jest potrzebna duża wiedza.
Rozważmy system kontroli lotów, w którym używa się radarów i innych detektorów do
wyznaczenia pozycji samolotu (rys. 2.4). Na rysunku 2.7 przedstawiono niektóre z
wielu dziedzin, z których specjaliści muszą być obecni w zespole inżynierów
systemowych.

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

W wypadku wielu systemów istnieje niemal nieskończona liczba

kompromisowych decyzji wyboru między różnymi typami podsystemów. Inżynierowie
różnych dziedzin muszą negocjować sposób realizacji funkcjonalności systemu. Nie
ma zwykle „poprawnej" decyzji, jak należy rozłożyć system na części. Jest za to wiele

innych możliwości. Wybór jednej z nich wcale nie musi być dokonany na podstawie
kryteriów technicznych. Przypuśćmy, że w systemie kontroli lotów jedną z opcji jest
zbudowanie nowych radarów, a nie wykorzystanie istniejącej instalacji. Jeśli
zatrudnieni inżynierowie lądowi nie mają wiele więcej do roboty, to mogą
faworyzować taki wybór, ponieważ umożliwia zachowanie swojego stanowiska.
Następnie uzasadniają go za pomocą argumentów technicznych.

Oprogramowanie jest niesłychanie elastyczne i dlatego wiele niespodziewanych

problemów zostawia się do rozwiązania inżynierom oprogramowania. Przypuśćmy, że
położenie radaru powoduje powstawanie podwójnego obrazu. Przeniesienie radaru
jest niemożliwe, trzeba więc innego sposobu radzenia sobie z podwójnym obrazem.
Rozwiązanie mogłoby polegać na poprawieniu oprogramowania przetwarzającego
obraz tak, aby wyeliminować efekt podwójnego obrazu. Może to zwiększyć niezbędną
moc procesora w systemie, która może stać się nierealna.

Inżynierowie oprogramowania często stają przed zadaniem zwiększenia

możliwości oprogramowania bez zwiększania kosztu sprzętu. Wiele tzw. „porażek
oprogramowania" nie wynikało z kłopotów związanych z oprogramowaniem. Były
rezultatem próby zmiany oprogramowania, aby dostosować je do zmienionych
wymagań inżynierii systemów. Dobrym przykładem takiej porażki jest niepowodzenie
systemu bagażowego na lotnisku w Denver (Swartz, 1996).

2.4.1. Definicja wymagań systemowych

Definiowanie wymagań systemowych ma na celu odkrycie wymagań stawianych

systemowi jako całości. Podobnie jak w wypadku analizy wymagań dla
oprogramowania, ten proces obejmuje konsultacje z klientami i użytkownikami. W tej
fazie definiowania wymagań zwykle koncentrujemy się na trzech rodzajach wymagań:

1. Abstrakcyjne wymagania funkcjonalne. Podstawowe funkcje, które system

ma wypełniać, są definiowane na wysokim poziomie abstrakcji. Szczegółowa
specyfikacja wymagań funkcjonalnych ma miejsce na poziomie
podsystemów. W wypadku systemu kontroli lotów czynność zbierania
wymagań prawdopodobnie doprowadzi do stwierdzenia, że jest konieczność
zbudowania bazy danych do przechowywania planów lotów wszystkich
samolotów wlatujących do kontrolowanej przestrzeni powietrznej. Szczegóły

tej bazy danych nie będą jednak specyfikowane, chyba że miałoby to wpływ
na wymagania stawiane innym podsystemom.

2. Właściwości systemu. Są to niefunkcjonalne, omówione wcześniej,

pojawiające się właściwości systemu. Może to być dostępność, efektywność i
bezpieczeństwo. Te niefunkcjonalne właściwości systemu mają wpływ na
wymagania stawiane wszystkim podsystemom.

3. 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ć. W specyfikacji systemu kontroli lotów można na
przykład ustalić, że system nie powinien jednocześnie podawać kontrolerowi
zbyt wiele informacji.

Ważną częścią fazy definicji wymagań jest ustalenie zbioru ogólnych celów,

które system ma osiągnąć. Nie muszą być one określone w kategoriach
funkcjonalności systemu, ale muszą zdefiniować, dlaczego system jest nabywany do
konkretnego środowiska.

Aby zilustrować różnicę między tymi dwoma podejściami, rozważmy

zainstalowany w biurowcu system zabezpieczeń przeciwko pożarom i włamaniom.
Określenie celu w kategoriach funkcjonalności systemu mogłoby być na przykład
takie:

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.

W sformułowaniu tego celu wyraźnie stwierdzono, że konieczny jest system

alarmowy, który będzie ostrzegał o niepożądanych zdarzeniach. Taka definicja jest
właściwa, gdy na przykład w budynku istnieje już system alarmowy, który trzeba
zamienić na nowy. Ten cel można jednak określić szerzej:

Zapewnić, aby normalna praca w biurowcu nie była poważnie zakłócana przez

pożary i włamania.

Zapisywanie celów w ten sposób jednocześnie zwiększa i zmniejsza zbiór

potencjalnych decyzji projektowych. Umożliwia zabezpieczenie budynku przed
włamaniami za pomocą skomplikowanych systemów zamków bez jakichkolwiek
wewnętrznych alarmów. Wyklucza za to użycie instalacji tryskaczowych do
zabezpieczenia przeciwpożarowego. Takie instalacje mogłyby uszkodzić instalację
elektryczną budynku i w ten sposób poważnie zakłócić pracę.

Zasadnicza trudność z określaniem wymagań stawianych systemowi polega na

tym, że 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. Jaskrawym przykładem takiego
problemu jest przewidywanie trzęsień ziemi. Nikt nie może dokładnie przewidzieć
położenia epicentrum trzęsienia ziemi, jego czasu, wpływu na miejscowe środowisko
itd. Nie możemy zatem całkowicie wyspecyfikować sposobu postępowania przy
poważnych trzęsieniach ziemi. Taki problem można rozwiązywać dopiero wówczas,
gdy się pojawi.

2.4.2. Projektowanie systemu

Projektowanie systemu (rys. 2.8) ma na celu określenie, jak funkcjonalność

systemu będzie realizowana przez jego poszczególne komponenty. Czynnościami

Rysunek 2.8 Proces projektowania systemu

tego procesu są:

1. Podziel wymagania. Analizuje się i łączy w grupy powiązane ze sobą

wymagania. Zwykle istnieje kilka możliwych sposobów podziału. W tej
fazie procesu można utworzyć kilka różnych opcji.

2. Zidentyfikuj podsystemy. Identyfikuje się różne podsystemy, które

samodzielnie lub zespołowo spełniają wymagania. Grupy wymagań są
zwykle skojarzone z podsystemami, a zatem tę czynność i grupowanie
wymagań można ze sobą połączyć. Identyfikacja podsystemów może
być jednak zależna od innych czynników zarówno organizacyjnych, jak i
środowiskowych.

3. 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ń. W praktyce nie
mamy jednak nigdy do czynienia z idealną zgodnością podziału
wymagań i zidentyfikowanych podsystemów. Z ograniczeń narzuconych
przez kupione na zewnątrz podsystemy (COTS, por. p. 2.4.3) może
wyniknąć konieczność zmiany wymagań.

4. Określ funkcjonalność podsystemów. Specyfikuje się poszczególne

funkcje realizowane przez podsystemy. Czynność tę można uważać za
część fazy projektowania systemu albo fazy specyfikacji wymagań, gdy
podsystem jest systemem oprogramowania. W tym kroku należy także
rozpoznać związki między podsystemami.

5. Zdefiniuj interfejsy podsystemów. Definiuje się interfejsy oferowane i

wymagane przez poszczególne podsystemy. Po ich uzgodnieniu można
równolegle pracować nad podsystemami.

Dwukierunkowe strzałki na rys. 2.8 oznaczają, że między każdą parą kroków

procesu projektowania występuje wiele iteracji i sprzężeń zwrotnych. Gdy pojawiają
się problemy i pytania, ponowne zajęcie się wcześniejszymi fazami jest często
nieuniknione.

Dla niemal wszystkich systemów istnieje wiele możliwych projektów, które

można by opracować. Obejmują cały zakres rozwiązań z różnymi kombinacjami
sprzętu, oprogramowania i pracy ludzkiej. Rozwiązanie wybrane do dalszej realizacji
może być najlepsze pod względem technicznym i spełniać wymagania. W wielu

wypadkach czynniki natury organizacyjnej i politycznej mają istotny wpływ na wybór
rozwiązania. Jeśli system jest na przykład przeznaczony dla instytucji rządowej,
dostawcy państwowi mogą mieć pierwszeństwo przed zagranicznymi, nawet gdy ich
produkty są technologicznie słabsze.

2.4.3. Tworzenie podsystemów
W czasie tworzenia podsystemów implementuje się podsystemy

zidentyfikowane w trakcie projektowania. Może to oznaczać rozpoczęcie kolejnego
procesu inżynierii systemów dla poszczególnych podsystemów. Jeśli jest to
podsystem oprogramowania, to prawdopodobnie rozpocznie się proces tworzenia
oprogramowania obejmujący gromadzenie wymagań, projektowanie, implementację
itd.

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. Zwykle kupienie istniejącego produktu jest znacznie tańsze niż stworzenie
własnego wyspecjalizowanego komponentu. W tej fazie prawdopodobnie należy
cofnąć się do projektowania, aby przystosować się do nowego kupionego
komponentu. Systemy COTS nie zawsze precyzyjnie spełniają wymagania, ale jeśli
produkty z półki są dostępne, to zwykle warto ponieść koszty rewizji projektu.

Różne systemy są zwykle tworzone równolegle. Przy problemach na pograniczu

między podsystemami trzeba opracować żądanie modyfikacji systemu. Jeśli system
wymaga obszernych prac inżynieryjnych nad sprzętem, to dokonywanie zmian po
rozpoczęciu produkcji jest zwykle bardzo kosztowne. Należy wówczas znaleźć jakieś
„obejścia" rozwiązujące taki problem. Te „obejścia" polegają przeważnie na zmianie
oprogramowania, ponieważ to właśnie ono jest swoiście elastyczne. Oznacza to
zmiany w wymaganiach stawianych oprogramowaniu. Ważne jest więc, jak
wspomniałem w rozdziale 1, aby projektować oprogramowanie z myślą o zmianach.

2.4.4. Integracja systemu

Integracja systemu polega na pobraniu niezależnie zbudowanych podsystemów

i scaleniu ich w jeden kompletny system. Integrację można przeprowadzić za pomocą
podejścia „wielkiego wybuchu", gdy wszystkie podsystemy są integrowane w tym
samym czasie. Z powodów technicznych i menedżerskich najlepiej jest jednak
integrować przyrostowo, tzn. w jednym kroku jest integrowany jeden system.Taki
przyrostowy proces jest najwłaściwszy z dwóch powodów:

1.

Zwykle nie da się ustalić harmonogramów budowania wszystkich
podsystemów tak, aby kończyły się w tym samym czasie.

2.

Integracja przyrostowa zmniejsza koszty wykrywania błędów. Jeśli integruje
się jednocześnie wiele podsystemów, to błąd wykryty w trakcie testowania
może występować w każdym z tych podsystemów. Gdy integruje się jeden
podsystem z już działającym systemem, zauważone błędy są
prawdopodobnie w integrowanym podsystemie lub w interakcji tego
podsystemu i już działających podsystemów.

Awarie podsystemów, które są konsekwencjami niewłaściwych założeń o innych

podsystemach, są zwykle wykrywane w trakcie integracji systemu. Może to
doprowadzić do sporów między dostawcami odpowiedzialnymi za różne podsystemy.
Po wykryciu błędów w interakcji podsystemów różni dostawcy mogą mieć odmienne
zdania o tym, kto za te błędy odpowiada. Negocjacje, jak rozwiązać te problemy,
mogą trwać wiele tygodni lub nawet miesięcy.

2.4.5. Instalacja systemu
W trakcie instalacji system jest umieszczany w środowisku, w którym ma

działać. Chociaż może to wyglądać na bardzo prosty proces, może tu pojawić się
wiele problemów. To oznacza, że instalacja złożonego systemu może zająć wiele
miesięcy, a nawet lat.

Przykładami tych problemów są:

1. Środowisko, w którym system ma być zainstalowany, jest inne niż to, które

zakładali twórcy systemu. Jest to najczęściej występujący problem w trakcie
instalacji systemów oprogramowania. System może na przykład korzystać z
funkcji oferowanych przez specyficzną wersję systemu operacyjnego. W
systemie operacyjnym w środowisku instalacji systemu te funkcje mogą nie być
identyczne. Po instalacji systemu może okazać się, że nie pracuje on w ogóle
albo pracuje zupełnie inaczej, niż przewidywali jego twórcy.

2. Potencjalni użytkownicy systemu mogą być wrogami jego wprowadzenia.

System może zmniejszyć zakres ich odpowiedzialności lub liczbę stanowisk w
firmie. Ludzie mogą więc rozmyślnie odmówić współpracy z instalatorami
systemu. Mogą na przykład nie wziąć udziału w szkoleniu operatorów lub
sprzeciwić się udostępnieniu podstawowych informacji dla procesu instalacji.

3. Nowy system ma koegzystować z istniejącym systemem do czasu przekonania

firmy, że nowy system pracuje poprawnie. Sprawia to szczególne problemy z
instalacją, jeśli systemy te nie są całkowicie niezależne, ale współdzielą pewne
komponenty. Instalacja nowego systemu może być niemożliwa bez usunięcia
starego. Próby z nowym systemem mogą się zatem odbywać jedynie w czasie,
gdy stary system nie jest używany.

4. Mogą wystąpić fizyczne problemy z instalacją. Wstawienie systemu do

istniejącego budynku może być niemożliwe z braku miejsca na kable sieciowe
w kanałach przewodowych, braku wymaganej klimatyzacji, zbyt małych mebli
itd. Jeśli system ma być instalowany w budynku zabytkowym, to jakiekolwiek
przebudowy będą prawdopodobnie zakazane.

2.4.6. Działanie systemu
Po zainstalowaniu system zaczyna działać. Uruchomienie systemu może

wymagać organizacji sesji szkoleniowych dla operatorów i zmiany normalnego toku
pracy, aby jak najefektywniej wykorzystać nowy system. Nie wykryte problemy mogą
pojawić się w tej fazie, ponieważ specyfikacja systemu mogła zawierać

Awarie podsystemów, które są konsekwencjami niewłaściwych założeń o innych

podsystemach, są zwykle wykrywane w trakcie integracji systemu. Może to
doprowadzić do sporów między dostawcami odpowiedzialnymi za różne podsystemy.
Po wykryciu błędów w interakcji podsystemów różni dostawcy mogą mieć odmienne
zdania o tym, kto za te błędy odpowiada. Negocjacje, jak rozwiązać te problemy,
mogą trwać wiele tygodni lub nawet miesięcy.

2.4.5. Instalacja systemu
W trakcie instalacji system jest umieszczany w środowisku, w którym ma

działać. Chociaż może to wyglądać na bardzo prosty proces, może tu pojawić się
wiele problemów. To oznacza, że instalacja złożonego systemu może zająć wiele
miesięcy, a nawet lat.

Przykładami tych problemów są:

1. Środowisko, w którym system ma być zainstalowany, jest inne niż to, które

zakładali twórcy systemu. Jest to najczęściej występujący problem w trakcie
instalacji systemów oprogramowania. System może na przykład korzystać z
funkcji oferowanych przez specyficzną wersję systemu operacyjnego. W
systemie operacyjnym w środowisku instalacji systemu te funkcje mogą nie być
identyczne. Po instalacji systemu może okazać się, że nie pracuje on w ogóle
albo pracuje zupełnie inaczej, niż przewidywali jego twórcy.

2. Potencjalni użytkownicy systemu mogą być wrogami jego wprowadzenia.

System może zmniejszyć zakres ich odpowiedzialności lub liczbę stanowisk w
firmie. Ludzie mogą więc rozmyślnie odmówić współpracy z instalatorami
systemu. Mogą na przykład nie wziąć udziału w szkoleniu operatorów lub
sprzeciwić się udostępnieniu podstawowych informacji dla procesu instalacji.

3. Nowy system ma koegzystować z istniejącym systemem do czasu przekonania

firmy, że nowy system pracuje poprawnie. Sprawia to szczególne problemy z
instalacją, jeśli systemy te nie są całkowicie niezależne, ale współdzielą pewne
komponenty. Instalacja nowego systemu może być niemożliwa bez usunięcia
starego. Próby z nowym systemem mogą się zatem odbywać jedynie w czasie,
gdy stary system nie jest używany.

4. Mogą wystąpić fizyczne problemy z instalacją. Wstawienie systemu do

istniejącego budynku może być niemożliwe z braku miejsca na kable sieciowe w
kanałach przewodowych, braku wymaganej klimatyzacji, zbyt małych mebli itd.
Jeśli system ma być instalowany w budynku zabytkowym, to jakiekolwiek
przebudowy będą prawdopodobnie zakazane.

2.4.6. Działanie systemu
Po zainstalowaniu system zaczyna działać. Uruchomienie systemu może

wymagać organizacji sesji szkoleniowych dla operatorów i zmiany normalnego toku
pracy, aby jak najefektywniej wykorzystać nowy system. Nie wykryte problemy mogą
pojawić się w tej fazie, ponieważ specyfikacja systemu mogła zawierać błędy i
opuszczenia. Chociaż system działa zgodnie ze specyfikacją, jego funkcjonalność
może nie spełniać prawdziwych potrzeb przedsiębiorstwa. Oznacza to, że projektanci
nie przewidzieli oczekiwanego trybu pracy z systemem.

Jednym z problemów, które mogą wyjść na jaw dopiero po uruchomieniu

systemu, jest współpraca nowego systemu z istniejącymi już systemami. Mogą
wystąpić fizyczne problemy z niekompatybilnością. Przeniesienie danych między
systemami może być trudne. Bardziej subtelne są problemy z bardzo różniącymi się
interfejsami użytkownika różnych systemów. Wprowadzenie nowego systemu może
doprowadzić do zwiększenia liczby błędów operatorów, ponieważ operatorom mogą
się mylić polecenia dostępne w różnych interfejsach użytkownika.

2.4.7. Ewolucja systemu
Czas życia wielkich złożonych systemów jest bardzo długi. W trakcie swego

działania systemy te muszą ewoluować, aby dało się usunąć błędy w pierwotnych
wymaganiach oraz spełnić nowe wymagania, które się pojawiły. Komputery systemu
będą prawdopodobnie wymienione na nowe szybsze maszyny. Firma, która używa
systemu, może się zreorganizować i używać systemu w całkiem inny sposób.
Zewnętrzne środowisko też może się zmienić, wymuszając zmiany w systemie.
Ewolucja systemu (podobnie jak omówiona w części 7 ewolucja oprogramowania) jest
ze swej natury kosztowna z kilku powodów:

1. Proponowane zmiany muszą być bardzo starannie rozważone z punktu

widzenia przedsiębiorstwa i technologii. Muszą być zaakceptowane przez
rozmaite osoby, zanim będą wprowadzone.

2. Podsystemy nigdy nie są całkowicie niezależne, zatem zmiany w jednym

systemie mogą źle wpłynąć na zachowanie i efektywność innych podsystemów.
Odpowiednie zmiany powinny być więc wprowadzone do tych podsystemów.

3. Przyczyny pierwotnych decyzji projektowych zwykle nie są zapisywane. Osoby

odpowiedzialne za ewolucję systemu muszą ustalić, dlaczego podjęto takie a nie
inne decyzje.

4. W miarę starzenia się systemu jego struktura staje się coraz bardziej

skomplikowana przez zmiany, a koszt wprowadzenia nowych zmian jest coraz
większy.
Wraz ze wzrostem zależności społeczeństwa od systemów rozmaitych

rodzajów, zwiększają się nakłady na ewolucję systemów, a nie rozwijanie nowych.
Istniejące systemy, które trzeba utrzymywać przy życiu, są czasem nazywane
odziedziczonymi.

2.4.8. Likwidacja systemu
Likwidacja systemu oznacza wycofanie go po okresie jego pożytecznego

użytkowania. Czasem jest to proste, niektóre jednak systemy mogą zawierać surowce
niebezpieczne dla środowiska. W swej działalności inżynierowie systemów powinni
przewidywać likwidację systemu i w trakcie projektowania wziąć pod uwagę utylizację
substancji systemu. Toksyczne chemikalia powinny być na przykład zamknięte w
szczelnych modułach, które po zużyciu można w całości usunąć.

W wypadku oprogramowania nie ma mowy o żadnych fizycznych problemach z

likwidacją. Pewne funkcje oprogramowania mogą jednak występować w systemie po
to, aby ułatwić proces likwidacji. Oprogramowanie może na przykład monitorować
stan innych komponentów systemu. Gdy system ulega likwidacji, nie zużyte
komponenty można zidentyfikować i ponownie użyć.

Jeśli dane przechowywane w likwidowanym systemie muszą być zachowane, to

należy je przekształcić i przenieść do innego systemu. Często może się to wiązać z
wysokimi kosztami, ponieważ struktury danych mogą być niejawnie zdefiniowane w
samym oprogramowaniu.

2.5. Zaopatrywanie w system
Klientami kupującymi złożone systemy komputerowe są zwykle duże

przedsiębiorstwa, na przykład 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 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ć.

Wielkie złożone systemy zwykle składają się z komponentów z półki (COTS)

oraz komponentów specjalnie zbudowanych. Jedną z przyczyn coraz większej
obecności oprogramowania w systemach jest jego elastyczność, która umożliwia
wykorzystanie większej liczby istniejących komponentów sprzętowych.
Oprogramowanie jest tu „klejem", który spaja te różne komponenty i umożliwia im
efektywną pracę. Potrzeba stworzenia sklejacza (glueware) powoduje czasem, że
oszczędności wynikające z użycia komponentów z półki wcale nie są takie wielkie.

Na rysunku 2.9 przedstawiono proces zaopatrywania w system w wypadku

systemu istniejącego, jak i takiego, który należy specjalnie zaprojektować. Oto istotne
uwagi na temat procesu z tego diagramu:

1. Komponenty z półki zwykle nie spełniają wymagań idealnie, chyba że

napisano te wymagania z myślą o tych właśnie komponentach. Wybór
systemu oznacza zatem znalezienie najlepszego dopasowania między
wymaganiami stawianymi systemowi a możliwościami systemów z półki.
Wymagania zmienią się w wyniku tego wyboru. Może to mieć kaskadowy
wpływ na inne podsystemy.

2. 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.

3. Po wybraniu wykonawcy systemu następuje okres negocjacji kontraktu, w

trakcie którego uzgadnia się dalsze zmiany wymagań i omawia różne
sprawy, na przykład koszt zmian.

Rysunek 2.9 Proces zaopatrywania w system

Większość podsystemów sprzętowych oraz wiele podsystemów

oprogramowania, na przykład systemy zarządzania bazą danych, nie jest specjalnie
tworzonych, gdy są częścią większego systemu. Używa się raczej istniejących
podsystemów, włączając je takimi, jakie są, lub adaptując do potrzeb tego systemu.

Bardzo niewiele 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 pewną liczbą podwykonawców. W wypadku wielkich systemów (np.
kontroli lotów) grupa dostawców może stworzyć konsorcjum, aby zdobyć ten kontrakt.
Takie konsorcjum powinno być zdolne do wykonania wszystkich prac związanych z
tym typem systemu, będzie więc obejmować dostawców sprzętu komputerowego,
wytwórców oprogramowania, dostawców urządzeń zewnętrznych i dostawców
specjalistycznego osprzętu, na przykład radarów.

Rysunek 2.10 Model wykonawca- -podwykonawca

Taki model wykonawca-podwykonawca zmniejsza liczbę przedsiębiorstw, z

którymi klient musi się kontaktować. Podwykonawcy projektują i tworzą części
systemu zgodnie ze specyfikacją opracowaną przez generalnego wykonawcę. Po ich
ukończeniu te części są integrowane przez generalnego wykonawcę. Są następnie
dostarczane klientowi kupującemu system. Zależnie od treści kontraktu klient może
wyrazić zgodę generalnemu wykonawcy na wolny wybór podwykonawców lub
wymagać wyboru z uzgodnionej listy firm

GŁÓWNE TEZY



Inżynieria systemów jest złożonym i trudnym procesem, który wymaga
wkładu pracy specjalistów wielu innych 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. Są to m.in. efektywność,
niezawodność, użyteczność, bezpieczeństwo i zabezpieczenia.
Powodzenie lub porażka systemu często zależy od tych pojawiających się
właściwości.



Architektury systemów zwykle prezentuje się na diagramach blokowych,
przedstawiających główne podsystemy i związki między nimi.



Typami komponentów funkcjonalnych systemu są komponenty
detektorowe, komponenty efektorowe, komponenty obliczeniowe,

komponenty koordynujące, komponenty komunikacyjne i komponenty
interfejsu.



Proces inżynierii systemów obejmuje specyfikację, projektowanie,
tworzenie, integrację i testowanie. Integracja systemu (łączenie
podsystemów od różnych dostawców tak, aby współpracowały) jest zwykle
najtrudniejsza i najważniejsza.



Proces zaopatrywania w system obejmuje specyfikację systemu,
ogłoszenie przetargu, wybór dostawcy i zawarcie kontraktu na dostawę
systemu. Niektóre części systemu komputerowego są kupowane jak
komercyjne komponenty z półki (COTS).