Inżynieria systemów
komputerowych
y
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.
Wyobraz
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ć z
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 dz
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 znalez
ć
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 Wykrywa ruch w monitorowanej
drzwiowy przestrzeni, wykrywa otwarcie
monitorowanych drzwi
Efektor Syrena Dz
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 wyraz
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 znalez
ć 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Ä… z
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
GA
Ó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).