Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Inżynieria oprogramowania – wykład 3 1 Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników,

Podobne prezentacje


Prezentacja na temat: "Inżynieria oprogramowania – wykład 3 1 Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników,"— Zapis prezentacji:

1 Inżynieria oprogramowania – wykład 3 1 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.

2 Inżynieria oprogramowania – wykład 3 2 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.

3 Inżynieria oprogramowania – wykład 3 3 Zawartość Modele procesu tworzenia oprogramowania Iteracja procesu Specyfikowanie oprogramowania Projektowanie i implementowanie oprogramowania Zatwierdzanie oprogramowania Ewolucja oprogramowania Zautomatyzowane wspomaganie procesu

4 Inżynieria oprogramowania – wykład 3 4 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.

5 Inżynieria oprogramowania – wykład 3 5 Modele procesów tworzenia 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.

6 Inżynieria oprogramowania – wykład 3 6 Model kaskadowy procesu tworzenia oprogramowania Definiowanie wymagań Projektowanie systemu i oprogramowania Implementacja i testowanie jednostek Integracja i testowanie systemu Działanie i pielęgnacja

7 Inżynieria oprogramowania – wykład 3 7 Problemy modelu kaskadowego Wynikiem każdej fazy jest przynajmniej jeden dokument podlegający akceptacji 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.

8 Inżynieria oprogramowania – wykład 3 8 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. Nie ma tu oddzielnych czynności specyfikacji, tworzenia i zatwierdzania, a są one raczej przeprowadzane równolegle z szybkim reagowaniem na informacje zwrotne.

9 Inżynieria oprogramowania – wykład 3 9 Tworzenie ewolucyjne Wersja początkowa Ogólny opis Specyfikacja Tworzenie Zatwierdzenie Wersje pośrednie Wersja końcowa Równolegle czynności

10 Inżynieria oprogramowania – wykład 3 10 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.

11 Inżynieria oprogramowania – wykład 3 11 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ą.

12 Inżynieria oprogramowania – wykład 3 12 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.)

13 Inżynieria oprogramowania – wykład 3 13 Tworzenie formalne systemów Definicja wymagań Specyfikacja formalna Przekształcenia formalne Integracja i testowanie systemu

14 Inżynieria oprogramowania – wykład 3 14 Przekształcenie formalne R1 P 1 Specyfikacja formalna Program wykonywalny

15 Inżynieria oprogramowania – wykład 3 15 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.

16 Inżynieria oprogramowania – wykład 3 16 Tworzenie z użyciem wielokrotnym W większości przedsięwzięć programistycznych występuje wielokrotne użycie oprogramowania. Dzieje się to zwykle nieformalnie, gdy zatrudnione osoby znają projekty lub kody programów podobne do tych wymaganych. Szukają ich, modyfikują zgodnie z wymaganiami i włączają do swojego systemu. Podstawa w modelu ewolucyjnym. 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.

17 Inżynieria oprogramowania – wykład 3 17 Tworzenie z użyciem wielokrotnym Specyfikacja wymagań Zatwierdzanie systemu Tworzenie i integracja Projekt systemu z użyciem wielokrotnym Analiza komponentów Modyfikacja wymagań

18 Inżynieria oprogramowania – wykład 3 18 Iteracja procesu Polega na powtarzaniu fragmentu procesu tworzenia oprogramowania w miarę ewolucji wymagań stawianych systemowi. N.p. prace projektowe i implementacyjne musza być ponownie wykonane, aby spełnić zmienione wymagania. Mamy tutaj dwa hybrydowe modele: tworzenie przyrostowe, tworzenie spiralne.

19 Inżynieria oprogramowania – wykład 3 19 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

20 Inżynieria oprogramowania – wykład 3 20 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 Do każdego przyrostu wybierany jest najlepszy proces tworzenia. Gdy usługi w pewnym przyroście mają staranną specyfikację, model kaskadowy może być użyty w tym przyroście. Gdy specyfikacja jest niejasna, lepiej zastosować tworzenie ewolucyjne.

21 Inżynieria oprogramowania – wykład 3 21 Zalety procesu tworzenia przyrostowego Klienci nie muszą 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.

22 Inżynieria oprogramowania – wykład 3 22 Programowanie ekstremalne (XP) Wynik ewolucji podejścia przyrostowego. Stworzone przez Kenta Becka w 1999 r. Opiera się ono na tworzeniu i dostarczaniu bardzo małych przyrostów funkcjonalności oraz włączeniu klienta w proces tworzenia. Ustawiczne poprawianie kodu i programowanie pozbawione indywidualizmu.

23 Inżynieria oprogramowania – wykład 3 23 Tworzenie spiralne Zaproponowany przez Bohema w 1998 r. Jest obecnie bardzo popularny. Proces tworzenia oprogramowania przedstawiany jest tutaj w postaci spirali. Każda pętla spirali reprezentuje jedną fazę procesu. Najbardziej wewnętrzna pętla może być poświęcona studium wykonalności systemu, następna definicji wymagań stawianych systemowi, kolejna projektowaniu itd.

24 Inżynieria oprogramowania – wykład 3 24 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

25 Inżynieria oprogramowania – wykład 3 25 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. Rysuje się szczegółowe plany zarządzania. Rozpoznaje zagrożenia przedsięwzięcia. Rozpoznanie i redukcja zagrożeń Przeprowadza się szczegółową analizę każdego z rozpoznanych zagrożeń przedsięwzięcia. Podejmuje się kroki zmierzające do redukcji tych zagrożeń. Tworzenie i zatwierdzanie Po ocenie zagrożeń wybiera się model tworzenia systemu. (prototypowanie ewolucyjne, przekształcenia formalne, model kaskadowy) Planowanie Recenzuje się przedsięwzięcie i podejmuje decyzję, czy rozpoczynać następną pętlę spirali.

26 Inżynieria oprogramowania – wykład 3 26 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żynierią 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ń.

27 Inżynieria oprogramowania – wykład 3 27 Proces inżynierii wymagań Modele systemu Modele systemu Dokumenta cja wymagań Określenie i analiza wymagań Specyfikacja wymagań Modele systemu Wymagania użytkownika systemu Zatwierdzanie wymagań Raport o wykonywalności Studium wykonalności Dokumentacja wymagań

28 Inżynieria oprogramowania – wykład 3 28 Projektowanie i implementowanie wymagań Faza implementowania w tworzeniu oprogramowania to proces przekształcania specyfikacji systemu w działający system Obejmuje zawsze projektowanie i programowanie, ale jeśli zastosowano podejście ewolucyjne, to może również zawierać udoskonalenie specyfikacji oprogramowania 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. Projekt opracowywany jest iteracyjnie poprzez wiele różnych wersji. Proces projektowania może obejmować opracowanie kilku modeli systemu na różnych poziomach abstrakcji.

29 Inżynieria oprogramowania – wykład 3 29 Charakterystyczne czynności procesu projektowania Projektowanie architektury Specyfikowanie abstrakcyjne Projektowanie interfejsów Projektowanie komponentów Projektowanie struktur danych Projektowanie algorytmów

30 Inżynieria oprogramowania – wykład 3 30 Ogólny model procesu projektowania Projektowanie architektury Specyfikowanie abstrakcyjne Projektowanie interfejsów Projektowanie komponentów Architektura systemu Specyfikacja programowania Specyfikacja interfejsów Specyfikacja komponentów Projektowanie struktury danych Specyfikacja struktury danych Specyfikacja algorytmów Projektowanie algorytmów Specyfikacja wymagań Produkty projektowania Czynności projektowe

31 Inżynieria oprogramowania – wykład 3 31 Metody projektowania Ciągle często projektowanie jest działaniem ad hoc, gdzie wymagania zapisuje się w języku naturalnym a następnie tworzy nieformalny projekt Lepsze podejście polega na użyciu metod strukturalnych, które są zbiorami notacji i porad dla projektantów oprogramowania. Ich użycie polega zwykle na opracowaniu graficznych modeli systemu i prowadzi do dużej ilości dokumentacji projektowej. Metody strukturalne mogą obejmować: modele przepływu danych, modele encja-związek, modele strukturalne, modele obiektowe.

32 Inżynieria oprogramowania – wykład 3 32 Programowanie 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. Testowanie wykazuje istnienie błędów. Usuwanie błędów polega na ich lokalizacji i poprawieniu. Lokalizacja błędu może wymaga nowych przypadków testowych.

33 Inżynieria oprogramowania – wykład 3 33 Proces usuwania błędów Napraw błąd Przetestuj program ponownie Zlokalizuj błąd Zaprojektuj naprawę błędu Napraw błąd

34 Inżynieria oprogramowania – wykład 3 34 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.

35 Inżynieria oprogramowania – wykład 3 35 Proces testowania Testowanie komponentów Testowanie modułów Testowanie podsystemów Testowanie systemów Testowanie odbiorcze Testowanie komponentów Testowanie integracji Testowanie przez użytkownika

36 Inżynieria oprogramowania – wykład 3 36 Fazy procesu testowania Testowanie komponentów (jednostek) Testuje się poszczególne komponenty, aby zapewnić, że działają poprawnie. Każdy komponent testowany jest niezależnie. 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. Testowane niezależnie 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 spełnienia wymagań funkcjonalnych i niefunkcjonalnych Testowanie odbiorcze Jest to końcowa faza procesu testowania przed przyjęciem systemu do użytkowania. System pierwszy raz testuje się na danych dostarczonych od uzytkownika

37 Inżynieria oprogramowania – wykład 3 37 Fazy testowania w procesie tworzenia oprogramowania Specyfikacja wymagań Specyfikacja systemu Projekt systemu 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 Test integracji systemu Test integracji podsystemu

38 Inżynieria oprogramowania – wykład 3 38 Testowanie alfa i beta Testowanie alfa jest testowaniem odbiorczym stosowanym, kiedy system jest tworzony dla jednego klienta. Proces testowania trwa do momentu osiągnięcia zgody pomiędzy wytwórcą systemu i klientem co do tego, że dostarczony system jest możliwą do przyjęcia implementacją wymagań. Testowanie beta stosuje się, kiedy system sprzedawany jako produkt programowy. Testowanie polega na dostarczeniu systemu pewnej liczbie potencjalnych klientów, którzy zgodzili się z niego korzystać. Klienci informują wytwórców o pojawiających się problemach.

39 Inżynieria oprogramowania – wykład 3 39 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 w oprogramowaniu 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.

40 Inżynieria oprogramowania – wykład 3 40 Ewolucja systemu Zidentyfikuj wymagania stawiane systemowi Zbadaj istniejące systemy Zaproponuj zmiany systemów Zmodyfikuj system Nowy system Istniejące systemy

41 Inżynieria oprogramowania – wykład 3 41 Zautomatyzowane wspomaganie procesu tworzenia oprogramowania Komputerowo wspomagana inżynieria oprogramowania (CASE) korzysta z różnego oprogramowania 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.

42 Inżynieria oprogramowania – wykład 3 42 Technologia CASE Technologia CASE jest obecnie dostępna dla większości rutynowych czynności procesu tworzenia oprogramowania. Ulepszenia wynikające z użycia CASE są ograniczone dwoma czynnikami: 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.

43 Inżynieria oprogramowania – wykład 3 43 Klasyfikacja narzędzi CASE Klasyfikacja narzędzi CASE pomaga zrozumieć różne typy narzędzi oraz ich rolę we wspomaganiu czynności tworzenia oprogramowania. Trzy perspektywy klasyfikacji narzędzi CASE: perspektywy funkcjonalności, w której klasyfikuje się narzędzia CASE względem ich specyficznej funkcji; perspektywy procesu, w której klasyfikuje się narzędzia CASE względem wspomaganych przez nie czynności procesu; perspektywy 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.

44 Inżynieria oprogramowania – wykład 3 44 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

45 Inżynieria oprogramowania – wykład 3 45 Klasyfikacja narzędzi CASE względem ich funkcji c.d. 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

46 Inżynieria oprogramowania – wykład 3 46 Podział systemów CASE ze względu na zakres wspomagania Narzędzia wspomagające poszczególne zadania w ramach procesu, np. sprawdzania 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. Zwykle składają się ze zbioru narzędzi w mniejszym lub większym stopniu zintegrowanych Środowiska wspomagają całość lub znaczną część procesu tworzenia oprogramowania. Zwykle składają się z kilku różnych warsztatów, które w pewien sposób zintegrowano.

47 Inżynieria oprogramowania – wykład 3 47 Narzędzia, warsztaty i środowiska Technologia CASE Narzędzia Warsztaty Środowiska Kompilatory Narzędzia do porównań plików Edytory Analiza i projektowanie Programowanie Testowanie Warsztaty do konkretnego języka Warsztaty ogólnego przeznaczenia Warsztaty do wielu metod Warsztaty do jednej metody Środowiska zintegrowane Środowiska zbudowane dla procesu

48 Inżynieria oprogramowania – wykład 3 48 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.

49 Inżynieria oprogramowania – wykład 3 49 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.

50 Inżynieria oprogramowania – wykład 3 50 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.


Pobierz ppt "Inżynieria oprogramowania – wykład 3 1 Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników,"

Podobne prezentacje


Reklamy Google