Inżynieria systemów komputerowych yró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. Wyobrazmy 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ć zle 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 dzwię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 Dzwię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 wyraznie 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ą zle 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).