Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Inżynieria oprogramowania Halina Tańska. Literatura: K. Subieta, Wprowadzenie do inżynierii oprogramowania, Wydawnictwo PJWSTK, Warszawa 2002 J. Górski,

Podobne prezentacje


Prezentacja na temat: "Inżynieria oprogramowania Halina Tańska. Literatura: K. Subieta, Wprowadzenie do inżynierii oprogramowania, Wydawnictwo PJWSTK, Warszawa 2002 J. Górski,"— Zapis prezentacji:

1 Inżynieria oprogramowania Halina Tańska

2 Literatura: K. Subieta, Wprowadzenie do inżynierii oprogramowania, Wydawnictwo PJWSTK, Warszawa 2002 J. Górski, Inżynieria oprogramowania w projekcie informatycznym, MIKOM, Warszawa 1999 J. Cheesman, J. Daniels, Komponenty w UML, WNT, Warszawa 2004 G. Schneider, J. P. Winters, Stosowanie przypadków użycia, WNT, Warszawa 2004 I. Sommerville, Inżynieria oprogramowania, WNT, Warszawa 2003 A. Jaszkiewicz, Inżynieria oprogramowania, Helion, Warszawa 1997 M. Fowler, UML w kropelce, Oficyna Wydawnicza LTP, Warszawa 2005 St. Wrycza, B. Marcinkowski, K. Wyrzykowski, Język UML 2.0 w modelowaniu systemów informatycznych, Helion 2005 P. Beynon-Davies, Inżynieria systemów informatycznych, WNT, Warszawa 1999 St. Wrycza, Ćwiczenia z UML, Helion 2007 A. Cockburn, Jak pisać efektywnie przypadki użycia, WNT, Warszawa 2000 W. Dąbrowski, A. Stasiak, M. Wolski, Modelowanie systemów informatycznych w języku UML 2.1 w praktyce, MIKOM, Warszawa 2007

3 Przedmiot inżynierii oprogramowania Inżynieria oprogramowania to wiedza techniczna dotycząca wszystkich faz cyklu życia oprogramowania. Traktuje oprogramowanie jako produkt, który ma spełniać potrzeby techniczne, ekonomiczne lub społeczne. Inżynieria oprogramowania to wiedza empiryczna, synteza doświadczenia tysięcy ośrodków zajmujących się budową oprogramowania.

4 Cechy dobrego oprogramowania: zgodne z wymaganiami użytkownika, niezawodne, efektywne, łatwe w konserwacji, ergonomiczne.

5 Zagadnienia inżynierii oprogramowania: sposoby prowadzenia przedsięwzięć informatycznych (PI), techniki planowania, szacowania kosztów, harmonogramowania i monitorowania PI, metody analizy i projektowania systemów, techniki zwiększania niezawodności oprogramowania, sposoby testowania systemów i szacowania niezawodności, sposoby przygotowania dokumentacji technicznej i użytkowej, procedury kontroli jakości, metody redukcji kosztów konserwacji (usuwania błędów, modyfikacji i rozszerzeń), techniki pracy zespołowej i czynniki psychologiczne wpływające na efektywność pracy.

6 Kryzys oprogramowania to: sprzeczność pomiędzy odpowiedzialnością systemu informatycznego (SI) a jego zawodnością; ogromne koszty utrzymania oprogramowania; niska kultura ponownego użycia wytworzonych komponentów projektów i oprogramowania (powtarzalność); długi i kosztowny cykl tworzenia oprogramowania; długi i kosztowny cykl życia SI oraz ciągłe zmiany; nieodpowiednie narzędzia i języki programowania; frustracje projektantów i programistów; uzależnienie organizacji od SI i przyjętych technologii; problemy współdziałania niezależnie zbudowanego oprogramowania; problemy przyswojenia istniejących systemów do nowych warunków.

7 Walka z kryzysem oprogramowania polega na: stosowaniu technik i narzędzi ułatwiających pracę nad złożonymi systemami; korzystanie z metod wspomagających analizę nieznanych problemów i ułatwiających wykorzystanie wcześniejszych doświadczeń; usystematyzowanie procesu wytwarzania oprogramowania tak, aby ułatwić jego planowanie i monitorowanie; wytworzenie wśród producentów i nabywców przekonania, że budowa dużego systemu wysokiej jakości jest zadaniem wymagającym profesjonalnego podejścia.

8 Źródła złożoności projektu oprogramowania: Podstawowy powód kryzysu oprogramowania - złożoność produktów informatyki i procesów ich wytwarzania. Źródła złożoności projektu oprogramowania to: dziedzina problemowa obejmująca ogromną liczbę wzajemnie uzależnionych aspektów; zespół projektantów podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji; środki i technologie informatyczne: sprzęt, oprogramowanie, sieć, języki, narzędzia, udogodnienia; potencjalni użytkownicy: czynniki psychologicznie, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność.

9 Złożoność - zasady postępowania zasada dekompozycji: rozdzielenie złożonego problemu na podproblemy, które można rozpatrywać i rozwiązywać niezależnie od siebie i niezależnie od całości; zasada abstrakcji: eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego przedmiotu lub mniej istotnej informacji; wyodrębnienie cech wspólnych i niezmiennych dla pewnego zbioru bytów i wprowadzaniu pojęć lub symboli oznaczających takie cechy; zasada ponownego użycia: wykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu, komponentów oprogramowania; zasada sprzyjania naturalnym ludzkim własnościom: dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do wrodzonych ludzkich własności psycholog.

10 Modelowanie pojęciowe projektant i programista muszą dokładnie wyobrazić sobie problem oraz metodę jego rozwiązania. Zasadnicze procesy tworzenia oprogramowania zachodzą w ludzkim umyśle; pojęcia modelowania pojęciowego (conceptual modelling) oraz modelu pojęciowego (conceptual model) odnoszą się do procesów myślowych i wyobrażeń towarzyszących pracy nad oprogramowaniem; modelowanie pojęciowe jest wspomagane przez środki wzmacniające ludzką pamięć i wyobraźnie. Służą one do przedstawienia rzeczywistości opisywanej przez dane, procesów zachodzących w rzeczywistości, struktur danych oraz programów składających się na konstrukcję systemu.

11 Perspektywy w modelowaniu pojęciowym percepcja rzeczywistego świata; analityczny model rzeczywistości; model struktur danych i procesów SI.

12 Metodyka Metodyka to spójny, logicznie uporządkowany zestaw metod i procedur technicznych oraz organizatorskich służących zespołowi wykonawczemu do analizy rzeczywistości a także projektowania pojęciowego, logicznego i/lub fizycznego; Metodyka jest to zestaw pojęć, notacji, modeli, języków, technik i sposobów postępowania służący do analizy dziedziny stanowiącej przedmiot projektowanego systemu oraz do projektowania pojęciowego, logicznego i/lub fizycznego. Metodyka jest powiązana z notacją służącą do dokumentowania wyników faz projektu (pośrednich, końcowych) jako środek wspomagający ludzką pamięć i wyobraźnię i jako środek komunikacji w zespołach oraz pomiędzy projektantami i klientami.

13 Składniki metodyki to: formalizmy, modele opisu rzeczywistości (dziedziny przedmiotowej), jej statyki i dynamiki; strukturalizacja procesu TSI (cykl życia); szczegółowe metody i techniki dokumentowania; narzędzia CASE; wymagania merytoryczne wobec poszczególnych twórców SI; kryteria oceny jakości projektu i systemu; zasady planowania i kierowania rozwojem systemu.

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

15 Cele Poznać pojęcie procesu tworzenia oprogramowania i modelu procesu tworzenia oprogramowania. Poznać kilka różnych modeli procesów tworzenia oprogramowania oraz wiedzieć, kiedy należy ich używać. Ogólnie rozumieć modele procesów inżynierii wymagań stawianych oprogramowaniu, tworzeniu oprogramowania, testowaniu i ewolucji. Wiedzieć czym jest technologia CASE wspomagająca proces tworzenia oprogramowania.

16 Zasadnicze czynności w procesie tworzenia oprogramowania Specyfikowanie oprogramowania. Funkcjonalność oprogramowania i ograniczenia jego działania muszą być zdefiniowane. Projektowanie i implementowanie oprogramowania. Oprogramowanie, które spełnia specyfikację, musi być stworzone. Zatwierdzenie oprogramowania. Wytworzone oprogramowanie musi spełniać oczekiwania klienta. Ewolucja oprogramowania. Oprogramowanie musi ewoluować, aby spełniać zmieniające się potrzeby użytkowników.

17 Cykl życia oprogramowania (systemu) system life cycle Cykl życia oprogramowania (systemu) to ciąg wyodrębnionych, wzajemnie spójnych faz i etapów, pozwalających na pełne, skuteczne zaprojektowanie, a następnie użytkowanie systemu informatycznego. Każda z faz korzysta z własnej grupy metod, technik i narzędzi wspomagania tworzenia oprogramowania.

18 Modele cyklu życia oprogramowania 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.

19 Modele cyklu życia oprogramowania model kaskadowy (wodospadowy) model spiralny prototypowanie montaż z gotowych komponentów

20 Model kaskadowy (wodospadowy) Definiowanie wymagań Projektowanie systemu i oprogramowania Implementacja i testowanie jednostek Integracja i testowanie systemu Działanie i pielęgnacja

21 Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Cele i szczegółowe wymagania wobec systemu. Szczegółowy projekt systemu uwzględniający wcześniejsze wymagania. Modyfikacje producenta - usunięcie błędów, zmiany i rozszerzenia. Analiza Model kaskadowy

22 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. Wadą 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.

23 Ocena modelu kaskadowego Wady modelu: narzucanie twórcom oprogramowania ścisłej kolejności wykonywania prac wysoki koszt błędów popełnionych we wczesnych fazach długa przerwa w kontaktach z klientem Z drugiej strony, jest on do pewnego stopnia niezbędny do planowania, harmonogramowania, monitorowania i rozliczeń finansowych.

24 Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Analiza Model kaskadowy z iteracjami

25 Zmodyfikowany model kaskadowy Definiowanie wymagań Projektowanie systemu i oprogramowania Implementacja i testowanie jednostek Integracja i testowanie systemu Działanie i pielęgnacja

26 Tworzenie ewolucyjne Tworzenie ewolucyjne polega na opracowaniu wstępnej implementacji, pokazaniu jej użytkownikowi z prośbą o komentarze i udoskonalaniu jej w wielu wersjach aż do powstania odpowiedniego systemu.

27 Tworzenie ewolucyjne Wersja początkow a Ogólny opis Specyfikacja Tworzenie Zatwierdzenie Wersje pośrednie Wersja końcowa Równolegle czynności

28 Typy tworzenia ewolucyjnego 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.

29 Tworzenie ewolucyjne Problemy –Proces nie jest widoczny –System ma złą 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ą.

30 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.)

31 Tworzenie formalne systemów Definicja wymagań Specyfikacja formalna Przekształcenie formalne Integracja i testowanie systemu

32 Formalne transformacje Wymagania na system są formułowane w pewnym formalnym języku, następnie poddawane są kolejnym transformacjom, aż do uzyskania działającego kodu. Transformacje są wykonywane bez udziału ludzi (czyli w istocie język specyfikacji wymagań jest nowym „cudownym” językiem programowania). Tego rodzaju pomysły nie sprawdziły się w praktyce. Nie są znane szersze ich zastosowania.

33 Przekształcenie formalne R1 P1 Specyfikacja formalna Program wykonywalny

34 Formalne transformacje Formalna specyfikacja wymagań Postać pośrednia Postać pośrednia Kod...

35 Tworzenie z użyciem wielokrotnym W większości przedsięwzięć programistycznych występuje wielokrotne użycie 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.

36 Tworzenie z użyciem wielokrotnym Specyfikacja wymagań Zatwierdzenie systemu Tworzenie i integracja Projekt systemu z użyciem wielokrotnym Analiza komponentów Modyfikacja wymagań

37 Iteracja procesu Potrzebne jest także wspomaganie procesu tworzenia oprogramowania nazywane iteracjami, które polega na powtarzaniu fragmentu tego procesu w miarę ewolucji wymagań stawianych systemowi. Przykładowo prace projektowe i implementacyjne musza być ponownie wykonane, aby spełnić zmienione wymagania. Mamy tutaj dwa hybrydowe modele: –tworzenie przyrostowe, –tworzenie spiralne.

38 Tworzenie przyrostowe Podejście przyrostowe do tworzenia zaproponował Mills (1980) 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

39 Tworzenie przyrostowe Zdefiniuj zarys wymagań Wytwórz przyrost systemu Przypisz wymagania do przyrostów Zweryfikuj przyrost Zaprojektuj architekturę systemu Zintegruj system Zweryfikuj system System końcowy System nie ukończony

40 Model spiralny Składa się z czterech faz realizowanych w kolejnych fazach: Planowanie: ustalenie celów produkcji kolejnych wersji systemu Analiza ryzyka (ew. budowa prototypu) Konstrukcja (model kaskadowy) Atestowanie (przez klienta). Jeżeli ocena nie jest w pełni pozytywna rozpoczynany jest kolejny cykl

41 Model spiralny Planowanie : Ustalenie planu kolejnej fazy Identyfikacja i analiza ryzyka (ew. budowa prototypu) Konstrukcja (model kaskadowy) Atestowanie (w tym przez klienta). Jeżeli ocena nie jest w pełni pozytywna, rozpoczynany jest kolejny cykl. Przegląd : Ustalenie celów, alternatywnych dróg i ograniczeń

42 Model spiralny procesu tworzenia oprogramowania Określ cele, inne strategie i ograniczenia Oceń inne strategie, rozpoznaj i zmniejsz zagrożenia RECENZJA Plan wymagań Plan cyklu życia Plan tworzenia Plan testowania i integracji Zaplanuj następną fazę Analiza zagrożeń Analiza zagrożeń Prototyp 1 Prototyp 2 Prototyp 3 Działający prototyp Sposób postępowania Symulacje, modele, miary odniesienia Zatwierdzenie wymagań Wymagania S/W Projekto- wanie produktu Weryfikacja i zatwierdzenie Działanie Testy akceptacji Testy integracji Testy jednostek Kodowanie Szczegółowe projekto- wanie Utwórz, zweryfikuj produkt następnego poziomu

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

44 Prototypowanie (prototyping) - fazy Sposób na uniknięcie zbyt wysokich kosztów błędów popełnionych w fazie określania wymagań. Zalecany w przypadku, gdy określenie początkowych wymagań jest stosunkowo łatwe. Fazy: ogólne określenie wymagań budowa prototypu weryfikacja prototypu przez klienta pełne określenie wymagań realizacja pełnego systemu zgodnie z modelem kaskadowym

45 Prototypowanie (prototyping) - cele wykrycie nieporozumień pomiędzy klientem a twórcami systemu wykrycie brakujących funkcji wykrycie trudnych usług wykrycie braków w specyfikacji wymagań Zalety: możliwość demonstracji pracującej wersji systemu możliwość szkoleń zanim zbudowany zostanie pełny system

46 Metody prototypowania niepełna realizacja: objęcie tylko części funkcji języki wysokiego poziomu: Smalltalk, Lisp, Prolog, 4GL,... wykorzystanie gotowych komponentów generatory interfejsu użytkownika: wykonywany jest wyłącznie interfejs, wnętrze systemu jest „podróbką” szybkie programowanie (quik-and-dirty): normalne programowanie, ale bez zwracania uwagi na niektóre jego elementy, np. zaniechanie testowania. Często ewolucyjnie przechodzi się od prototypu do końcowego systemu

47 Montaż z gotowych komponentów Kładzie nacisk na możliwość redukcji nakładów przez wykorzystanie podobieństwa tworzonego oprogramowania do wcześniej tworzonych systemów oraz wykorzystanie gotowych komponentów dostępnych na rynku. Temat jest określany jako ponowne użycie (reuse) Metody: zakup elementów ponownego użycia od dostawców przygotowanie elementów poprzednich przedsięwzięć do ponownego użycia

48 Montaż z gotowych komponentów Zalety: wysoka niezawodność zmniejszenie ryzyka efektywne wykorzystanie specjalistów narzucanie standardów Wady: dodatkowy koszt przygotowania elementów ponownego użycia ryzyko uzależnienia się od dostawcy elementów niedostatki narzędzi wspomagających ten rodzaj pracy


Pobierz ppt "Inżynieria oprogramowania Halina Tańska. Literatura: K. Subieta, Wprowadzenie do inżynierii oprogramowania, Wydawnictwo PJWSTK, Warszawa 2002 J. Górski,"

Podobne prezentacje


Reklamy Google