Wstęp. Podstawy inżynierii oprogramowania. Slajdy na podstawie podręcznika: Iana Sommerville a Inżynieria oprogramowania

Transkrypt

1 Wstęp Podstawy inżynierii oprogramowania Slajdy na podstawie podręcznika: Iana Sommerville a Inżynieria oprogramowania Slajd 1 Inżynieria oprogramowania Gospodarki wszystkich rozwiniętych krajów zależą od oprogramowania Coraz więcej i więcej systemów wymaga niezawodnego oprogramowania Inżynieria oprogramowania zajmuje się teorią, metodami i narzędziami związanymi z wytwarzaniem oprogramowania Obecnie wytwarzanie oprogramowania jest poważną gałęzią gospodarki narodowej rozwiniętego kraju Slajd 2

2 Koszty oprogramowania Koszty oprogramowania są często dominującym składnikiem kosztów całego systemu. Zdarza się, że koszt oprogramowania znacznie przekracza samą wartość sprzętu komputerowego np. komputera osobistego. Koszt utrzymania i konserwacji oprogramowania jest większy niż koszt jego wytworzenia. Wieloletnia konserwacja oprogramowania może kosztować wielokrotnie więcej niż jego zakup. Inżynieria oprogramowania zajmuje się efektywnymi metodami wytwarzania i implementowania oprogramowania. Slajd 3 Co to jest oprogramowanie? Są to programy komputerowe, cała związana z nimi dokumentacja i dane konfiguracyjne Rodzaje produktów oprogramowania Powszechne Dostosowane (na zamówienie) Slajd 4

3 Co to jest inżynieria oprogramowania? Jest to dziedzina inżynierii, która obejmuje wszystkie aspekty tworzenia oprogramowania od fazy początkowej do jego pielęgnacji Inżynierowie oprogramowania pracują w sposób systematyczny i uporządkowany ponieważ jest to najskuteczniejszy sposób tworzenia oprogramowania wysokiej jakości Slajd 5 Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyka? Zasadniczo informatyka obejmuje teorie i podstawowe zasady działania komputerów. Inżynieria oprogramowania obejmuje praktyczne problemy związane z tworzeniem oprogramowania Byłoby dobrze gdyby inżynier programowania znał teorie informatyczne, z drugiej strony nie zawsze przystają one do rzeczywistości Slajd 6

4 Jaka jest różnica pomiędzy inżynierią oprogramowania a inżynierią systemów? Inżynieria systemów komputerowych obejmuje wszystkie aspekty tworzenia i ewolucji systemów komputerowych, w których oprogramowanie odgrywa zasadniczą rolę. Inżynierowie systemów biorą udział w specyfikacji systemu i definiowania jego ogólnej architektury Slajd 7 Co to jest proces tworzenia oprogramowania? Jest to zbiór czynności i związanych z nimi wyników, które zmierzają do opracowania produktu programowego Zasadnicze czynności wspólne dla wszystkich procesów Specyfikacja oprogramowania Tworzenie oprogramowania Zatwierdzenie oprogramowania Ewolucja oprogramowania Slajd 8

5 Co to jest model procesu tworzenia oprogramowania? Jest to uproszczona prezentacja procesu tworzenia oprogramowania. Modele ze swej natury są uproszczeniami Przykłady takich modeli: Model przepływu prac Model przepływu danych (lub model czynności) Model rola-akcja Przykłady ogólnych modeli (paradygmatów) tworzenia oprogramowania Model kaskadowy Tworzenie ewolucyjne Formalne przekształcenia Składanie systemu z komponentów ponownego użycia Slajd 9 Jakie są koszty inżynierii oprogramowania? Koszty wytworzenia oprogramowania można w przybliżeniu określić na 60%, natomiast 40% stanowią koszty testowania. Ewolucja oprogramowania może przewyższyć koszty jego wytworzenia Koszty zmian oprogramowania użytkowanego przez długi okres czasu mogą kilkukrotnie przekroczyć koszty jego wytworzenia Koszty zależą od stosowanego modelu Slajd 10

6 Co to są metody inżynierii oprogramowania? To jest uporządkowane podejście do tworzenia oprogramowania, które obejmuje Opisy modeli systemu Np. Modele obiektów, modele przepływu itp. Reguły Ograniczenia, którym podlegają modele systemu Zalecenia Heurystyki, które określają dobre zwyczaje projektantów Poradnictwo Opisy czynności, które należy wykonać Slajd 11 Co to jest CASE (Computer-Aided Software Engineering) CASE obejmuje rożne programy wykorzystane do wspomagania czynności procesu tworzenia oprogramowania (np. edytory notacji, generatory kodów) Upper-CASE Związane z początkowymi fazami tworzenia oprogramowania Lower-CASE Wspomagają implementowanie i testowanie Slajd 12

7 Jakie właściwości ma dobre oprogramowanie? Konkretny zbiór właściwości zależy od zastosowania, niemniej można podąć ogólny zbiór właściwości Zdolność do pielęgnacji Zdolność do ewolucji zgodnie z potrzebami klientów Niezawodność Nie powinno powodować fizycznych lub ekonomicznych katastrof w przypadku awarii Efektywność Nie powinno marnotrawić zasobów systemu takich jak pamięć czy czas procesora Użyteczność Powinno być użyteczne, bez zbędnego wysiłku ze strony użytkownika (np. interfejsy) Slajd 13 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ść. Slajd 14

8 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. Slajd 15 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 Slajd 16

9 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. Slajd 17 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. Slajd 18

10 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. Slajd 19 Typy pojawiających się właściwoś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. 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. Slajd 20

11 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 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. Slajd 21 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ę. Niezawodność operatora Jakie jest prawdopodobieństwo błędu operatora systemu? Slajd 22

12 Czynniki 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óra można by łatwo naprawić, przeradza się w poważny problem wymagający całkowitego wyłączenia systemu. Slajd 23 Efektywność i użyteczność Są trudne do oceny, można je jednak zmierzyć po uruchomieniu systemu. Mamy do czynienia nie z atrybutem ogólnego zachowania systemu, ale z zachowania systemu, które nie powinno mieć miejsca. System zabezpieczony to taki, który nie dopuszcza nieuprawnionego dostępu do swoich danych. Slajd 24

13 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. Slajd 25 Hierarchia systemów Miasto Ulica Budynek System System System wodnoogrzewania energetyczny kanalizacyjny System System System zsypów zabezpieczeń oświetlenia na śmieci Slajd 26

14 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? Slajd 27 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. Slajd 28

15 Prosty system antywłamaniowy Detektory ruchu Detektory drzwiowe Centralka alarmu Syrena Syntezator mowy Automat dzwoniący Zewnętrzne centrum monitoringu Slajd 29 Typy komponentów systemu antywłamaniowego Detektor detektor ruchu, detektor drzwiowy Efektor syrena Komunikacja automat dzwoniący Koordynacja centralka alarmu Interfejs syntezator mowy Slajd 30

16 Komponenty funkcjonalne systemu Komponenty detektorowe Komponenty efektorowe (uruchamiające) Komponenty obliczeniowe Komponenty komunikacyjne Komponenty koordynujące Komponenty interfejsu Slajd 31 Komponenty funkcjonalne 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. Slajd 32

17 Komponenty funkcjonalne 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. 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. Slajd 33 Proces 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 w trakcie tworzenia systemu. Jedną z przyczyn znaczenia oprogramowania w systemach jest jego elastyczność. Slajd 34

18 Proces inżynierii systemów Definicja wymagań Likwidacja systemu Projektowanie systemu Ewolucja systemu Tworzenie podsystemów Instalacja systemu Integracja systemu Slajd 35 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 Slajd 36

19 Definicja 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ć. Ważną częścią fazy definicji wymagań jest ustalenie zbioru ogólnych celów, które system ma osiągnąć. Slajd 37 Cele systemu 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. Cele organizacyjne Zapewnić, aby normalna praca w biurowcu nie była poważnie zakłócona przez pożary i włamania. Slajd 38

20 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. Slajd 39 Projektowanie 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. Slajd 40

21 Proces projektowania systemu Podziel wymagania Zdefiniuj interfejsy podsystemów Zidentyfikuj podsystemy Określ funkcjonalność podsystemów Przypisz wymagania podsystemom Slajd 41 Trudności przy projektowaniu 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 maja istotny wpływ na wybór rozwiązania. Slajd 42

22 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. Slajd 43 Integracja systemu 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. Slajd 44

23 Problemy instalacji Ś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ą. Slajd 45 Działanie systemu 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. Slajd 46

24 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. Slajd 47 Likwidacja systemu Likwidacja systemu oznacza wycofanie go po okresie jego pożytecznego użytkowania. Utylizacja substancji systemu. W wypadku oprogramowania nie ma mowy o żadnych fizycznych problemach z likwidacją. Slajd 48

25 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. Slajd 49 Proces zaopatrywania w system Systemy z półki są dostępne Zaadaptuj wymagania Wybierz system Ogłoś przetarg Wybierz dostawcę Zbadaj rynek w poszukiwaniu istniejących systemów Wyślij zapytanie ofertowe Wybierz ofertę Negocjuj kontrakt Podpisz kontrakt na budowanie Wymagany jest system na zamówienie Slajd 50

26 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. Slajd 51 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. Slajd 52

27 Model wykonawca - podwykonawca Klient potrzebujący systemu Generalny wykonawca Podwykonawca 1 Podwykonawca 2 Podwykonawca 3 Slajd 53 Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu programowego. Może to być tworzenie oprogramowania od zera, ale coraz częściej nowe oprogramowanie powstaje przez rozszerzanie i modyfikowanie istniejących systemów. Slajd 54

28 Zasadnicze czynności Specyfikowanie oprogramowania. Funkcjonalność oprogramowania i ograniczenia jego działania musza być zdefiniowane. Projektowanie i implementowanie oprogramowania. Oprogramowanie, które spełnia specyfikację, musi być stworzone. Zatwierdzenie oprogramowania. Oprogramowanie musi być zweryfikowane, aby zapewnić, że robi to, czego oczekiwał klient. Ewolucja oprogramowania. Oprogramowanie musi ewoluować, aby spełniać zmieniające się potrzeby użytkowników. Slajd 55 Ogólne modele systemów Model kaskadowy W tym modelu podstawowe czynności specyfikowania, tworzenia, zatwierdzania i ewolucji są odrębnymi fazami procesu. Tworzenie ewolucyjne W tym procesie czynności specyfikowania, projektowania i zatwierdzania przeplatają się. Tworzenie formalne systemu To podejście jest oparte na budowaniu formalnych matematycznych specyfikacji systemu i przekształcaniu tych specyfikacji w program za pomocą metod matematycznych. Tworzenie z użyciem wielokrotnym W tym podejściu zakłada się istnienie dużej liczby komponentów zdatnych do ponownego użycia. Slajd 56

29 Model kaskadowy Definiowanie wymagań Definiowanie wymagań Projektowanie systemu i oprogramowania Implementacja i testowanie jednostek Integracja i testowanie systemu Działanie i pielęgnacja Slajd 57 Fazy modelu kaskadowego Definiowanie i analiza wymagań Projektowanie systemu i analiza wymagań Implementacja i testowanie jednostek Integracja i testowanie systemu Działanie i pielęgnacja Slajd 58

30 Problemy modelu kaskadowego Następnej fazy nie powinno się rozpoczynać, jeśli poprzednia się nie zakończy. Koszty opracowania i akceptacji dokumentów są wysokie i dlatego iteracje są również kosztowne oraz wymagają powtarzania wielu prac. Wada modelu kaskadowego jest zawarty w nim nieelastyczny podział na rozłączne etapy. Model kaskadowy powinien być używany jedynie wówczas, gdy wymagania są jasne i zrozumiałe. Slajd 59 Tworzenie ewolucyjne Tworzenie badawcze Celem procesu jest praca z klientem, polegająca na badaniu wymagań i dostarczeniu ostatecznego systemu. Tworzenie rozpoczyna się od tych części systemu, które są dobrze rozpoznane. System ewoluuje przez dodawanie nowych cech, które proponuje klient. Prototypowanie z porzuceniem Celem procesu tworzenia ewolucyjnego jest zrozumienie wymagań klienta i wypracowanie lepszej definicji wymagań stawianych systemowi. Budowanie prototypu ma głównie na celu eksperymentowanie z tymi wymaganiami użytkownika, które są niejasne. Slajd 60

31 Tworzenie ewolucyjne Równolegle czynności Specyfikacja Wersja początkow a Ogólny opis Tworzenie Wersje pośrednie Zatwierdzenie Wersja końcowa Slajd 61 Tworzenie ewolucyjne Problemy Proces nie jest widoczny System ma nieelastyczną strukturę Konieczne mogą być specjalne narzędzia i techniki Stosowanie W wypadku systemów małych (mniej niż wierszy kodu) lub średnich (do wierszy kodu) z krótkim czasem życia podejście ewolucyjne jest najlepsze. W wypadku dużych systemów o długim czasie życia wady tworzenia ewolucyjnego ujawniają się jednak z całą ostrością. Slajd 62

32 Tworzenie formalne systemów Tworzenie formalne systemów jest podejściem, które ma wiele wspólnego z modelem kaskadowym. Proces tworzenia jest tu jednak oparty na matematycznych przekształceniach specyfikacji systemu w program wykonywalny. W procesie przekształcania formalna matematyczna reprezentacja systemu jest metodycznie przekształcana w bardziej szczegółowe, ale wciąż matematycznie poprawne reprezentacje systemu. Podejście z przekształceniem złożone z ciągu małych kroków jest łatwiejsze w użyciu. Wybór, które przekształcenie zastosować, wymaga jednak dużych umiejętności. Najlepiej znanym przykładem takiego formalnego procesu tworzenia jest Cleanroom, pierwotnie opracowany przez IBM (Proces Cleanroom jest oparty na przyrostowym tworzeniu oprogramowania, gdy formalnie wykonuje się każdy krok i dowodzi jego poprawności.) Slajd 63 Tworzenie formalne systemów Definicja wymagań Specyfikacja formalna Przekształcenie formalne Integracja i testowanie systemu Slajd 64

33 Przekształcenie formalne Przekształcenie formalne T1 T2 T3 T4 Specyfikacja formalna R1 R2 R3 Program wykonywalny P1 P2 P3 P4 Proofs of tran sformationcorrectness Slajd 65 Problemy i stosowalność Oprócz specjalistycznych dziedzin procesy oparte na przekształceniach formalnych są używane rzadko. Wymagają specjalistycznej wiedzy i w praktyce okazuje się, że w wypadku większości systemów nie powodują zmniejszenia kosztów lub polepszenia jakości w porównaniu z innymi podejściami. Interakcje systemów nie poddają się łatwo specyfikowaniu formalnemu. Slajd 66

34 Tworzenie z użyciem wielokrotnym W większości przedsięwzięć programistycznych występuje użycie wielokrotne oprogramowania. Etapy procesu Analiza komponentów Modyfikacja wymagań Projektowanie systemu z użyciem wielokrotnym Tworzenie i integracja Zakłada się istnienie wielkiego zbioru dostępnych komponentów programowych użycia wielokrotnego oraz integrującej je struktury. Slajd 67 Tworzenie z użyciem wielokrotnym Specyfikacja wymagań Analiza komponentów Modyfikacja wymagań Projekt systemu z użyciem wielokrotnym Tworzenie i integracja Zatwierdzeni e systemu Slajd 68

35 Iteracja procesu Potrzebne jest wspomaganie iteracji procesu, która polega na powtarzaniu fragmentu w miarę ewolucji wymagań stawianych systemowi. Prace projektowe i implementacyjne musza być ponownie wykonane, aby spełnić zmienione wymagania. Dwa hybrydowe modele Tworzenie przyrostowe Tworzenie spiralne Slajd 69 Tworzenie przyrostowe Podejście przyrostowe do tworzenia zaproponował Mills jako sposób na ograniczenie powtarzania prac w procesie tworzenia oraz danie klientom pewnych możliwości odkładania decyzji o szczegółowych wymaganiach do czasu, aż zdobędą pewne doświadczenia w pracy z systemem. W procesie przyrostowym klienci identyfikują w zarysie usługi, które system ma oferować. Wskazują, które z nich są dla nich najważniejsze, a które najmniej ważne. Definiuje się następnie pewną liczbę przyrostów, które maja być dostarczone. Gdy przyrost jest już gotowy i dostarczony, klienci mogą go uruchomić. Oznacza to, że szybko otrzymują część funkcjonalności systemu Slajd 70

36 Tworzenie przyrostowe Zdefiniuj zarys wymagań Przypisz wymagania do przyrostów Zaprojektuj architekturę systemu Wytwórz przyrost systemu Zweryfikuj przyrost Zintegruj system Zweryfikuj system System końcowy System nie ukończony Slajd 71 Zalety procesu tworzenia przyrostowego Klienci nie musza czekać na dostarczenie całego systemu, zanim zaczną czerpać z niego korzyść. Klienci mogą używać wstępnych przyrostów jako rodzaju prototypu i zdobywać doświadczenia, które inspirują wymagania wobec późniejszych przyrostów. Ryzyko całkowitej porażki przedsięwzięcia jest mniejsze. Usługi o najwyższym priorytecie będą dostarczane jako pierwsze. Slajd 72

37 Programowanie ekstremalne Opiera się ono na tworzeniu i dostarczaniu bardzo małych przyrostów funkcjonalności. Ustawiczne poprawianie kodu i programowanie pozbawione indywidualizmu. Slajd 73 Tworzenie spiralne Każda pętla spirali reprezentuje jedną fazę procesu. Najbardziej wewnętrzna pętla może być poświęcona wykonalności systemu, następna definicji wymagań stawianych systemowi, kolejna projektowaniu itd.. Slajd 74

38 Model spiralny procesu tworzenia oprogramowania Określ cele, inne strategie i ograniczenia Analiza zagrożeń Analiza zagrożeń Oceń inne strategie, rozpoznaj i zmniejsz zagrożenia RECENZJA Analiza zagrożeń Analiza zagrożeń Prototyp 1 Prototyp 2 Prototyp 3 Działający prototyp Zaplanuj następną fazę Plan wymagań Plan cyklu życia Plan tworzenia Plan testowania i integracji Sposób postępowania Zatwierdzenie wymagań Weryfikacja i zatwierdzenie Testy akceptacji działanie Symulacje, modele, miary odniesienia Szczegółowe Wymagania projektowanie S/W Projektowanie kodowanie produktu Testy integracji Testy jednostek Utwórz, zweryfikuj produkt następnego poziomu Slajd 75 Każda pętla spirali jest podzielona na cztery sektory: Ustalanie celów Definiuje się konkretne cele tej fazy przedsięwzięcia. Identyfikuje się ograniczenia, którym podlega proces i produkt. Rozpoznanie i redukcja zagrożeń Przeprowadza się szczegółową analizę każdego z rozpoznanych zagrożeń przedsięwzięcia. Tworzenie i zatwierdzanie Po ocenie zagrożeń wybiera się model tworzenia systemu. Planowanie Recenzuje się przedsięwzięcie i podejmuje decyzję, czy rozpoczynać następną pętlę spirali. Slajd 76

39 Specyfikowanie oprogramowania Ma na celu określenie, jakich usług wymaga się od systemu i jakim ograniczeniom podlega tworzenie i działanie oprogramowania. Ta czynność jest obecnie bardzo często nazywana inżynieria wymagań. W procesie inżynierii wymagań możemy wyróżnić cztery główne fazy: Studium wykonalności Określenie i analiza wymagań Specyfikowanie wymagań Zatwierdzanie wymagań Slajd 77 Proces inżynierii wymagań Studium wykonalności Określenie i analiza wymagań Specyfikacja wymagań Raport o wykonywalności Modele systemu Zatwierdzanie wymagań Wymagania Modele użytkownika systemu systemu Dokumentacja wymagań cja wymagań Slajd 78

40 Projektowanie i implementowanie wymagań Faza implementowania w tworzeniu oprogramowania to proces przekształcania specyfikacji systemu w działający system Projekt oprogramowania to opis struktury oprogramowania, które ma być zaimplementowane, danych, które są częścią systemu, interfejsów między komponentami systemu i użytych algorytmów. Proces projektowania może obejmować opracowanie kilku modeli systemu na różnych poziomach abstrakcji. Slajd 79 Charakterystyczne czynności procesu projektowania Projektowanie architektury Specyfikowanie abstrakcyjne Projektowanie interfejsów Projektowanie komponentów Projektowanie struktur danych Projektowanie algorytmów Slajd 80

41 Ogólny model procesu projektowania Specyfikacja wymagań Czynności projektowe Projektowanie architektury Specyfikowanie abstrakcyjne Projektowanie interfejsów Projektowanie komponentów Projektowanie struktury danych Projektowanie algorytmów Architektura systemu Specyfikacja programowania Specyfikacja interffejsów Specyfikacja komponentów Specyfikacja struktury danych Specyfikacja algorytmów Slajd 81 Metody projektowania Są zbiorami notacji i porad dla projektantów oprogramowania. Użycie metod strukturalnych polega zwykle na opracowaniu graficznych modeli systemu i prowadzi do ogromnej ilości dokumentacji projektowej. Modele: Model przepływu danych Model strukturalny Model obiektowy Slajd 82

42 Projektowanie i wyszukiwanie błędów Programiści wykonują pewne testy kodu, który napisali. Często prowadzi to do wykrycia błędów, które należy usunąć z programu. Testowanie usterek i usuwanie błędów to dwa różne procesy. Lokalizacja błędu może wymaga nowych przypadków testowych. Slajd 83 Proces usuwania błędów Zlokalizuj błąd Zaprojektuj naprawę błędu Napra Napraw w błąd błąd Napraw błąd Przetestuj program ponownie Slajd 84

43 Zatwierdzanie oprogramowania Weryfikacja i zatwierdzenie (W&Z) mają wykazać, że system jest zgodny ze swoją specyfikacją i spełnia oczekiwania klienta, który go kupuje. Obejmuje proces sprawdzania, m.in. kontrole i recenzje w każdym kroku procesu tworzenia od definicji wymagań użytkownika do pisania programów. Większość kosztów zatwierdzania powstaje po zaimplementowaniu, gdy testuje się działający system. Slajd 85 Proces testowania Testowanie jednostek Testowanie modułów Testowanie Testowanie komponentów podsystemów Testowanie integracji Testowanie systemów Testowanie odbiorcze Testowanie przez użytkownika Slajd 86

44 Fazy procesu testowania Testowanie jednostek Testuje się poszczególne komponenty, aby zapewnić, że działają poprawnie. Testowanie modułów Moduł jest kolekcją niezależnych komponentów takich jak klasy obiektów, abstrakcyjne typy danych, albo bardziej luźną kolekcją procedur i funkcji. Testowanie podsystemów Ta faza obejmuje testowanie kolekcji modułów, które zintegrowano w podsystemie. Testowanie systemu Podsystemy zintegrowano już w system. Ten proces testowania ma wykryć błędy wynikające z nie przewidzianych interakcji między podsystemami i problemów z interfejsami podsystemów. Testowanie odbiorcze Jest to końcowa faza procesu testowania przed przyjęciem systemu do użytkowania. Slajd 87 Fazy testowania Specyfikacja wymagań Specyfikacja systemu Projekt systemu i Projekt szczegółowy Plan testów odbiorczych Plan testów integracji systemu Plan testów integracji podsystemów Kod modułów i jednostek oraz ich test Działanie Test odbiorczy ttest integracji systemu Test integracji podsystemu Slajd 88

45 Ewolucja oprogramowania Elastyczność systemów oprogramowania jest jedną z głównych przyczyn, że coraz więcej i więcej oprogramowania włącza się do wielkich, złożonych systemów. Zmiany mogą być wprowadzone w każdej chwili tworzenia lub nawet po jego zakończeniu. Koszt tych zmian może być bardzo wysoki, ale wciąż będzie niższy niż odpowiednie zmiany w sprzęcie systemu. Slajd 89 Ewolucja systemu Zidentyfikuj wymagania stawiane systemowi Zbadaj istniejące systemy Zaproponuj zmiany systemów Zmodyfikuj system Istniejące systemy Nowy system Slajd 90

46 Zautomatyzowane wspomaganie procesu Komputerowo wspomagana inżynieria oprogramowania (CASE) jest nazwą oprogramowania używanego do wspomagania czynności procesu tworzenia oprogramowania, takich jak inżynieria wymagań, projektowanie, programowanie i testowanie. Czynności, które można zautomatyzować za pomocą CASE: Oprogramowanie graficznych modeli systemu jako części specyfikacji wymagań i projektu oprogramowania. Czynności projektu za pomocą słownika danych, który przechowuje informacje o encjach i związkach w projekcie. Generowanie interfejsu użytkownika na podstawie graficznego opisu interfejsu opracowanego interaktywnie przez użytkownika. Śledzenie błędów przez udostępnienie informacji o wykonującym się programie. Automatyczne tłumaczenie programów ze starych wersji języków programowania. Slajd 91 Technologia CASE Technologia CASE jest obecnie dostępna dla większości rutynowych czynności procesu tworzenia oprogramowania. Oprogramowanie jest głównie czynnością projektowania opartą na kreatywnym myśleniu. Istniejący system CASE automatyzuje rutynowe czynności, ale próby zastosowania sztucznej inteligencji do wspomagania programowania nie były udane. W większości firm inżynieria oprogramowania jest czynnością zespołową. Inżynierowie spędzają więc sporo czasu na interakcji z innymi członkami zespołu. Technologia CASE nie daje tu żadnego wsparcia. Slajd 92

47 Klasyfikacja CASE Klasyfikacja CASE pomaga zrozumieć różne typy narzędzi CASE oraz ich rolę we wspomaganiu czynności tworzenia oprogramowania. Perspektywa funkcjonalności, w której klasyfikuje się narzędzia CASE względem ich specyficznej funkcji. Perspektywa procesu, w której klasyfikuje się narzędzia CASE względem wspomaganych przez nie czynności procesu. Perspektywa integracji, w której klasyfikuje się narzędzia CASE względem sposobu ich integracji w spójne jednostki, które oferują wspomaganie jednej lub więcej czynności procesu. Slajd 93 Klasyfikacja narzędzi CASE względem ich funkcji Narzędzia do planowania Narzędzia PERT, narzędzia do szacowania, arkusze kalkulacyjne Narzędzia do edycji Edytory tekstowe, edytory diagramów, procesory tekstów Narzędzia do zarządzania zmianami Narzędzia do śledzenia wymagań, systemy kontroli zmian Narzędzia do zarządzania konfiguracjami System do zarządzania wersjami, narzędzia do budowania systemów Narzędzia do prototypowania Języki bardzo wysokiego poziomu, generatory interfejsu użytkownika Narzędzia do wspomagania metod Edytory projektów, słowniki danych i generatory kodów Narzędzia do przetwarzania języków Kompilatory, interpretatory Slajd 94

48 Klasyfikacja narzędzi CASE względem ich funkcji Narzędzia do analizy programów Generatory wzajemnych odwołań, analizatory statyczne, analizatory dynamiczne Narzędzia do testowania Dane testowe, programy porównujące pliki Narzędzia do usuwania błędów Systemy interakcyjnego usuwania błędów Narzędzia do dokumentowania Programy składu, edytory rysunków Narzędzia do wyszukiwania Systemy wyszukiwania wzajemnych odwołań, programy do restrukturyzacji systemów Slajd 95 Podział systemów CASE Narzędzia wspomagające poszczególne zadania w ramach procesu, np. ssprawdzania spójności projektu, kompilacji programu, porównywania wyników testów itd. Warsztaty wspomagają całe fazy procesów lub czynności, np. specyfikowanie, projektowanie itd. Środowiska wspomagają całość lub znaczną część procesu tworzenia oprogramowania. Slajd 96

49 Narzędzia, warsztaty i środowiska Technologia T CASE W Narzędzia Warsztaty Środowiska Edytory Kompilatory Narzędzia do po równań plików Środowiska zintegrowane Środowiska zbudo wane dla procesu Analiza i pro -jektowanie projektowanie testowanie Warsztaty do wielu metod Warsztaty do jednej metody Warsztaty ogólnego przeznaczenia Warsztaty do kon -kretnego języka Slajd 97 Główne tezy Procesy tworzenia oprogramowania to czynności zmierzające do wyprodukowania systemu. Modele procesów tworzenia oprogramowania to abstrakcyjne reprezentacje tych procesów. Wszystkie procesy tworzenia oprogramowania obejmują specyfikowanie, projektowanie, implementację, zatwierdzanie i ewolucje oprogramowania. Ogólne modele procesów opisują organizację procesu tworzenia oprogramowania. Przykładami takich modeli są: model kaskadowy, tworzenie ewolucyjne, tworzenie formalne systemów oraz tworzenie z użyciem wielokrotnym. W modelach iteracyjnych procesów tworzenie oprogramowania przedstawia się w postaci cyklu czynności. Zaletą tego podejścia jest uniknięcie zbyt wczesnego zatwierdzenia specyfikacji lub projektu. Przykładami modeli iteracyjnych są tworzenie przyrostowe i model spiralny. Slajd 98

50 Główne tezy Inżynieria wymagań to proces opracowywania specyfikacji oprogramowania. Obejmuje przygotowanie specyfikacji zrozumiałej dla użytkowników systemu oraz bardziej szczegółowej specyfikacji dla budowniczych systemu. Proces projektowania i implementowania polega na przekształceniu specyfikacji wymagań w działający system oprogramowania. Metody systematycznego projektowania mogą być elementem tego przekształcenia. Zatwierdzenie oprogramowania to proces sprawdzania, czy system jest zgodny ze swoją specyfikacją oraz czy spełnia rzeczywiste potrzeby użytkowników. Slajd 99 Główne tezy Ewolucja oprogramowania polega na modyfikowaniu istniejącego systemu oprogramowania, tak aby spełniał nowe wymagania. Takie podejście staje się standardem tworzenia oprogramowania w wypadku małych i średnich przedsięwzięć. Technologia CASE zapewnia zautomatyzowane wspomaganie procesu tworzenia oprogramowania. Narzędzia CASE wspomagają poszczególne czynności procesu. Warsztaty CASE wspomagają zbiory powiązanych czynności. Środowiska CASE wspomagają większość lub nawet wszystkie czynności procesu tworzenia oprogramowania. Slajd 100