Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 1 Inżynieria systemów komputerowych Inżynieria systemów to czynność specyfikowania, projektowania,

Podobne prezentacje


Prezentacja na temat: "Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 1 Inżynieria systemów komputerowych Inżynieria systemów to czynność specyfikowania, projektowania,"— Zapis prezentacji:

1 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 1 Inżynieria systemów komputerowych Inżynieria systemów to czynność specyfikowania, projektowania, implementowania, weryfikowania, wdrażania i pielęgnacji systemów postrzegana jako całość.

2 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 2 Cele Dowiedzieć się, dlaczego oprogramowanie w systemie pozostaje pod wpływem ogólniejszych zagadnień inżynierii systemów. Być wprowadzonym 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.

3 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 3 Zawartość Pojawiające się właściwości systemu Systemy i ich środowiska Modelowanie systemu Proces inżynierii systemów Zaopatrywanie w system

4 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 4 Co to jest system? System jest celową kolekcją powiązanych ze sobą komponentów, które współpracują, aby osiągnąć pewien cel. 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.

5 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 5 Problemy instrukcji systemów Duże systemy są z reguły przeznaczone do rozwiązywania skomplikowanych zadań. Inżynieria systemowa wymaga dużego wysiłku koordynacyjnego: wzajemne związki pomiędzy komponentami, wymóg zrozumienia innych dziedzin inżynierii. Systemy muszą być trwałe.

6 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 6 Oprogramowanie, a inżynieria systemowa Wzrasta rola oprogramowania np. w powszechnie stosowanych urządzeniach elektronicznych. Ogólnie rzec biorąc problemy inżynierii systemów są podobne do problemów inżynierii oprogramowania. Przez nieporozumienie problem oprogramowania jest spostrzegany jako problem inżynierii systemowej.

7 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 7 Właściwości systemów 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. 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.

8 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 8 Przykłady 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.

9 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 9 Typy pojawiających się właściwości systemu 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. 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.

10 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 10 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 systemów. 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. Niezawodność systemu

11 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 11 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ę. Niezawodność operatora Jakie jest prawdopodobieństwo błędu operatora systemu? Czynniki wpływające na niezawodność całego systemu

12 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 12 Zależność czynników niezawodności 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ą mogą mieć wpływ na działanie sprzętu, co prowadzi do dalszych błędów i tak dalej, i tak dalej. Awaria jednego podsystemu, którą można by łatwo naprawić, przeradza się w poważny problem wymagający całkowitego wyłączenia systemu.

13 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 13 Efektywność i użyteczność, bezpieczeństwo i zabezpieczenia Efektywność i użyteczność są trudne do oceny, można je jednak zmierzyć po uruchomieniu systemu. Bezpieczeństwo i zabezpieczenia: mamy tutaj do czynienia nie z atrybutem ogólnego zachowania systemu, ale z zachowania systemu, które nie powinno mieć miejsca. Np. system zabezpieczony to taki, który nie dopuszcza nieuprawnionego dostępu do swoich danych.

14 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 14 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. W ogólniejszym wypadku składa się ono z pewnej liczby oddziałujących na siebie systemów.

15 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 15 Hierarchia systemów System System System zsypów zabezpieczeń oświetlenia na śmieci System System System wodno- ogrzewania energetyczny kanalizacyjny Miasto Ulica Budynek

16 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 16 Ludzkie i organizacyjne czynniki obecne w środowisku systemu Zmiany procesu Czy system wymaga zmian w procesach pracy wykonywanej w środowisku? Zmiany zawodu Czy system zmniejsza umiejętności użytkowników i sprawia, że muszą zmienić swój styl pracy? Zmiany organizacyjne Czy system zmienia strukturę ośrodków władzy politycznej w organizacji?

17 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 17 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. 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.

18 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 18 Prosty system antywłamaniowy Syrena Detektory drzwiowe Centralka alarmu Syntezator mowy Zewnętrzne centrum monitoringu Detektory ruchu Automat dzwoniący

19 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 19 Komponenty funkcjonalne systemu Komponenty detektorowe zbierają informacje. Komponenty efektorowe (uruchamiające) powodują zmiany w środowisku systemu. Komponenty obliczeniowe wytwarzają wyniki. Komponenty komunikacyjne łącza różne komponenty. Komponenty koordynujące koordynują operacje innych komponentów. Komponenty interfejsu przetwarzają reprezentacje danych.

20 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 20 Przykłady komponentów funkcjonalnych systemu 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.

21 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 21 C.d. przykładów komponentów funkcjonalnych systemu Komponenty komunikacyjne Umożliwiają komunikację innym komponentom systemu. Przykładem takiego komponentu jest sieć łącząca różne komputery wewnątrz budynku. Komponenty koordynujące Koordynują operacje innych komponentów. Np. w układach czasu rzeczywistego jest to komponent szeregujący zadania. 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.

22 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 22 Charakterystyka procesu inżynierii systemów Interdyscyplinarna zawiłość: wiele różnych dziedzin inżynierii wchodzi w skład inżynierii systemów. Ograniczona możliwość modyfikacji systemu w trakcie jego tworzenia: zmiana raz podjętych decyzji dotyczących systemu często jest bardzo kosztowna, ale wtedy można jeszcze – odpowiadając na nowe wymagania - wykorzystać elastyczność oprogramowania.

23 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 23 Proces inżynierii systemów Definicja wymagań Projektowanie systemu Tworzenie podsystemów Integracja systemu Instalacja systemu Ewolucja systemu Likwidacja systemu

24 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 24 Interdyscyplinarna zawiłość inżynierii systemów Inżynieria oprogramowania Inżynieria elektroniczna Inżynieria mechaniczna Inżynieria strukturalna Inżynieria systemu kontroli lotów Projektowanie interfejsu użytkownika Inżynieria lądowa Inżynieria elektryczna Architektura

25 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 25 Rodzaje wymagań systemowych Trzy rodzaje wymagań: abstrakcyjne wymagania funkcjonalne: podstawowe funkcje, które system ma wypełniać są definiowane na wysokim poziomie abstrakcji; właściwości systemu: są to niefunkcjonalne, pojawiające się właściwości systemu; 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ć.

26 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 26 Dwojaki sposób definiowania wymagań systemowych Ważną częścią fazy definicji wymagań jest ustalenie zbioru ogólnych celów, które system ma osiągnąć. (1) Funkcjonalność systemu 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. (2) Cele organizacyjne Zapewnić, aby normalna praca w biurowcu nie była poważnie zakłócona przez pożary i włamania.

27 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 27 Trudność z określaniem wymagań stawianych systemowi 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.

28 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 28 Proces projektowania systemu Podziel wymagania Analizuje się i łączy w grupy powiązane ze sobą wymagania. Zwykle istnieje kilka możliwych sposobów podziału. Zidentyfikuj podsystemy Identyfikuje się różne podsystemy, które samodzielnie lub zespołowo spełniają wymagania. 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ń. Określ funkcjonalność podsystemów Specyfikuje się poszczególne funkcje realizowane przez podsystemy. Zdefiniuj interfejsy podsystemów Definiuje się interfejsy oferowane i wymagane przez poszczególne podsystemy.

29 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 29 Diagram procesu projektowania systemu Podziel wymagania Zdefiniuj interfejsy podsystemów Przypisz wymagania podsystemom Zidentyfikuj podsystemy Określ funkcjonalność podsystemów

30 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 30 Trudności z określaniem wymagań stawianych systemowi Objęcie wymaganiami całego zakresu rozwiązań z rożnymi kombinacjami sprzętu, oprogramowania i pracy ludzkiej. Oczekiwanie, ze system będzie od razu funkcjonował bez zarzutu. Czynniki natury organizacyjnej i politycznej mają istotny wpływ na wybór rozwiązania.

31 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 31 Tworzenie podsystemów W czasie tworzenia podsystemów implementuje się podsystemy zidentyfikowane w trakcie projektowania. 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. Różne systemy są zwykle tworzone równolegle.

32 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 32 Z powodów technicznych i menedżerskich najlepiej jest jednak integrować przyrostowo, tzn. w jednym kroku jest integrowany jeden system. Zwykle nie da się ustalić harmonogramów budowania wszystkich podsystemów tak, aby kończyły się w tym samym czasie. Integracja przyrostowa zmniejsza koszty wykrywania błędów. Awarie podsystemów, które są konsekwencjami niewłaściwych założeń o innych podsystemach, są zwykle wykrywane w trakcie integracji systemu. Integracja systemu

33 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 33 Środowisko, w którym system ma być zainstalowany, jest inne niż to, które zakładali twórcy systemu. Potencjalni użytkownicy systemu mogą być wrogami jego wprowadzenia. Nowy system ma koegzystować z istniejącym systemem do czasu przekonania firmy, że nowy system pracuje poprawnie. Mogą wystąpić fizyczne problemy z instalacją. Problemy instalacji

34 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 34 Uruchomienie systemu może wymagać organizacji sesji szkoleniowych dla operatorów i zmiany normalnego toku pracy. Nie wykryte problemy mogą pojawić się w tej fazie, ponieważ specyfikacja systemu mogła zawierać błędy i opuszczenia. Współpraca nowego systemu z istniejącymi już systemami: niekompatybilność, zwiększenie liczby błędów operatora, poprzez mylenie poleceń dostępnych w różnych interfejsach. Działanie systemu

35 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 35 Ewolucja systemu Czas życia wielkich złożonych systemów jest bardzo długi. W trakcie swego działania systemy te musza ewoluować. Ewolucja oprogramowania jest ze swej natury kosztowna: proponowane zmiany muszą być bardzo starannie rozważone z punktu widzenia przedsiębiorstwa i technologii, podsystemy nigdy nie są całkowicie niezależne, przyczyny pierwotnych decyzji projektowych zwykle nie są zapisywane, w miarę starzenia się systemu jego struktura staje się coraz bardziej skomplikowana przez zmiany.

36 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 36 Likwidacja systemu Likwidacja systemu oznacza wycofanie go po okresie jego pożytecznego użytkowania. Utylizacja substancji systemu. W wypadku samego oprogramowania, w odróżnieniu od całego systemu, nie ma mowy o żadnych fizycznych problemach z likwidacją.

37 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 37 Zaopatrywanie w system Klientami kupującymi złożone systemy komputerowe są zwykle duże przedsiębiorstwa, np. 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.

38 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 38 Proces zaopatrywania w system Zaadaptuj wymagania Wybierz system Wyślij zapytanie ofertoweWybierz ofertęNegocjuj kontrakt Podpisz kontrakt na budowanie Wybierz dostawcęOgłoś przetarg Zbadaj rynek w poszukiwaniu istniejących systemów Systemy z półki są dostępne Wymagany jest system na zamówienie

39 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 39 Problemy zaopatrywania Komponenty z półki zwykle nie spełniają wymagań idealnie, chyba że napisano te wymagania z myślą o tych właśnie komponentach. Gdy system będzie budowany na zamówienie, specyfikacja wymagań jest podstawą kontraktu na zamówienie w system. Po wybraniu wykonawcy systemu następuje okres negocjacji kontraktu, w trakcie którego uzgadnia się dalsze zmiany wymagań i omawia różne sprawy, np. koszt zmian.

40 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 40 Wykonawcy i podwykonawcy Bardzo wiele 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 pewna liczbą podwykonawców. Takie konsorcjum powinno być zdolne do wykonania wszystkich prac związanych z tym typem systemu.

41 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 41 Model wykonawca - podwykonawca Klient potrzebujący systemu Generalny wykonawca Podwykonawca 1 Podwykonawca 2 Podwykonawca 3

42 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 42 Główne tezy Inżynieria systemów jest złożonym i trudnym procesem, który wymaga wkładu pracy specjalistów wielu 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. Architektury systemów zwykle prezentuje się na diagramach blokowych, przedstawiających główne podsystemy i związki między nimi.

43 Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 43 Główne tezy c.d. Typami komponentów funkcjonalnych systemu są komponenty detektorowe, komponenty detektorowe, komponenty obliczeniowe, komponenty koordynujące, komponenty komunikacyjne i komponenty interfejsu. Proces inżynierii systemów obejmuje specyfikację, projektowanie, tworzenie, integrację i testowanie. Proces zaopatrywania w system obejmuje specyfikację systemu, ogłoszenie przetargu, wybór dostawcy i zawarcie kontraktu na dostawę systemu.


Pobierz ppt "Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2Slajd 1 Inżynieria systemów komputerowych Inżynieria systemów to czynność specyfikowania, projektowania,"

Podobne prezentacje


Reklamy Google