Zakres wykładu. Podstawy InŜynierii Oprogramowania

Transkrypt

1 Zakres wykładu Pojęcia podstawowe InŜynierii Oprogramowania Proces wytwarzania oprogramowania Artefakty procesu wytwarzania i ich modele Jakość oprogramowania Literatura: [1] Sacha K., InŜynieria oprogramowania, WNT 2009 [2] Pressman R.S., Praktyczne podejście do inŝynierii oprogramowania, WNT 2003 [3] Hamlet D., Maybee J., Podstawy techniczne inŝynierii oprogramowania, WNT 2003 [4] Fowler M., UML 2.0 w kropelce, Micom 2006 [5] Cocburn A., Jak pisać efektywne przypadki uŝycia, WNT,

2 Wykład 1 - WPROWADZENIE InŜynieria oprogramowania Procesy cyklu Ŝycia oprogramowania Modele cyklu Ŝycia oprogramowania Metodyki wytwarzania oprogramowania 2

3 Wzrost rozmiaru oprogramowania 3

4 KRYZYS wytwarzania 4

5 Ceny kryzysu Koszt 1godz. upadku systemu 5

6 Inne Podstawy InŜynierii Oprogramowania Przyczyny niepowodzeń 6 Nierealne oczekiwania Niejasne cele Nierealny czas Nowa technologia Niekompletne wymagania i specyfikacja Zmieniane wymagania i specyfikacja Brak wsparcia kierownictwa Niekompetencja technologiczna Brak zasobów Brak aktywności uŝytkownika

7 Historia sukcesów projektów informatycznych Wzrost sukcesu realizacji przedsięwzięć informatycznych (dzięki stosowaniu inŝynierii oprogramowania?) 30 tys. projektów róŝnych wielkości w USA 7

8 INśYNIERIA wiedza matematyczna i przyrodnicza zdobyta podczas studiowania oraz wynikająca z doświadczeń i praktyki, która jest stosowana do opracowania takich metod działania, by wykorzystać ekonomicznie materiały i naturę, na rzecz dobra człowieka OPROGRAMOWANIA* zestaw programów komputerowych, procedur i dokumentacji; pojęcie InŜynieria Oprogramowania (IO) pojawiło się 1968 r; podejście inŝynierskie to reakcja na tzw. kryzys oprogramowania 8

9 4 x P elementy IO Produkt (co) Projekt (realizacja) Proces (sposób) Personel (kto) PRODUKT = OPROGRAMOWANIE wykonuje funkcje (usługi) ma jakość 9

10 Cykl Ŝycia oprogramowania obejmuje okres Ŝycia oprogramowania -od pojawienia się koncepcji (potrzeby) posiadania i stosowania oprogramowania, - do momentu jego wycofania z uŝycia. 10

11 Procesy cyklu Ŝycia oprogramowania [ISO12207:1998] 11

12 Procesy cyklu Ŝycia oprogramowania perspektywa udziałowców stosuje stosuje Proces nabywania stosuje kontrakt Proces zarządzania Proces dostawy PERSPEKTYWA KONTRAKTU Nabywca, Dostawca MenadŜer stosuje stosuje stosuje PERSPEKTYWA ZARZĄDZANIA stosuje Proces eksploatacji Operator, UŜytkownik stosuje PERSPEKTYWA DZIAŁANIA stosuje Proces konserwacji stosuje Proces wytwarzania PERSPEKTYWA INśYNIERII Producent, Serwisant PROCESY WSPOMAGAJĄCE: dokumentowanie weryfikacja zarządzanie konfiguracją walidacja rozwiązywanie problemów przegląd wspólny zapewnienie jakości audyt PROCESY ORGANIZACYJNE infrastruktura doskonalenie szkolenie PERSPEKTYWA WSPOMAGANIA Pracownik ProcesówWs pomag. [ISO12207:1998] 12

13 [ISO12207:2008] 13

14 Model cyklu Ŝycia oprogramowania sposób organizacji wybranych procesów cyklu Ŝycia oprogramowania i wykonywanych w ich ramach czynności. Zwykle rozwaŝa się procesy: wytwórcze zarządcze 14

15 Modele cyklu Ŝycia oprogramowania kryterium: kompletność wymagań (ISO 12207): - kaskadowy - przyrostowy - ewolucyjny (syn. prototypowanie) kryteria dodatkowe: -iteracyjny powtarzalność działań -spiralny zarządzany ryzykiem 15

16 Model kaskadowy (1970, Royce) ustalone wymagania Określenie wymagań Zaleta: proste planowanie procesu wytwarzania Analiza Projektowanie opcjonalna Implementacja Testowanie Wada: Konserwacja w praktyce nie działa (w tej czystej postaci) 16

17 Model kaskadowy + (Royce 1973) A tak jest realizowany w praktyce model kaskadowy 17

18 Model kaskadowy + Definicja wymagań Zaleta: nawroty Analliza Projekt elastyczność realizacji Kodowanie Testy systmu Wada: dodatkowe koszty ( np. dokumentacji) Instalacja i konwersja UŜywanie i utrzymywanie 18

19 Przyrost 1 W Przyrost 2 Podstawy InŜynierii Oprogramowania Model przyrostowy P K/T I/W P K/T I/W Zalety: -szybkie wykrywanie usterek - szybkie dostarczanie częściowej implementacji Przyrost n P K/T I/W W - wymagania P - projekt MoŜliwy przepływ informacji K/T - kodowanie i testy I/W - instalacja i wsparcie Wady: - trudniejsze planowanie - dodatkowe koszty wg ISO

20 Model ewolucyjny (prototypowania) W 1 Przyrost 1 P K/T I/W W 2 Przyrost 2 Zaleta: P K/T I/W uniknięcie niezrozumienia wymagań W n Przyrost n P K/T I/W MoŜliwy przepływ informacji W - wymagania P - projekt K/T - kodowanie i testy I/W - instalacja i wsparcie Wada: koszty (budowanie wielu rozwiązań) wg ISO

21 Model spiralny Zaleta: szybka identyfikacja ryzyka Wada: koszty!! [Boehm,1988] 21

22 METODYKA WYTWARZANIA OPROGRAMOWANIA to wszystko, co jest systematycznie wykonywane w celu wytworzenia oprogramowania (np. dobór pracowników, zadań, zasady współpracy, procedury postępowania); => kaŝda organizacja ma swoją własną, niepowtarzalną metodykę. 22

23 Atrybuty metodyki Zakres metodyki określa, które fazy wytwarzania oprogramowania są objęte metodyką, jakie role i aktywności metodyka definiuje. Rozmiar metodyki jest liczbą typów elementów kontrolowanych w metodyce (wytwarzany artefakt,, miara jakości, opis techniki, itd.). Ceremoniał metodyki (stopień formalizacji) określa wymagany stopień precyzji, nakładu pracy i stopnia formalizacji dokumentów (duŝy, średni, mały). Waga metodyki to koncepcyjny iloczyn rozmiaru i ceremoniału dla poszczególnych elementów kontrolnych. Widzialność łatwość oceny, czy projekt jest wykonywany zgodnie z metodyką. 23

24 Kategorie metodyk wytwarzania: wg paradygmatu - strukturalne - obiektowo-zorientowane wg złoŝoności - regularne/cięŝkie: obszerna dokumentacja - elastyczne/ zwinne: komunikacja słowna 24

25 Metodyka wytwarzania oprogramowania jest procesem, a jej definicja jest wykorzystuje definicje trzech podstawowych pojęć: rola (ang. role), zadanie (ang. task), produktu pracy (ang. work product). [SPEM 2008] 25

26 Metodyki sterowane modelami [RUP 2003] 2009/

27 Generyczna metodyka USDP* fazy i dyscypliny FAZY USDP : Zapoczątkowanie Opracowanie Konstrukcja Przejście Specyfikacja wymagań Analiza Projektowanie Implementacja Testowanie Iter(1) iter(2) *USDP- Unified Software Development Process iter iter (n-1) (n) 27

28 Metodyka USDP CHARAKTERYSTYKA sterowany przez przypadki uŝycia zorientowany na opis architektury iteracyjny przyrostowy Proces USDP powtarza się przez wiele cykli, z których kaŝdy daje na końcu gotowy produkt PODSTAWOWY ZESTAW MODELI USDP model przypadków uŝycia model analizy model projektowy model rozmieszczenia model implementacyjny model testów 28

29 Metodyka RUP* fazy i dyscypliny *RUP- RationalUnified Process [RUP,2003] 29

30 Metodyki AUP* v1.1 fazy i dyscypliny *AUP- Agile Unified Process; rodzina metodyk 30

31 SCRUM- przykład metodyki AUP 31

32 Dziedzina zastosowań Podstawy InŜynierii Oprogramowania Język UML* w obiektowym procesie wytwarzania oprogramowania 6 Modelowanie biznesowe Analiza System UML Projektowanie *UML - Unified Modeling Language C++, Java, etc 32

33 Język UML Abstrakcyjny Pozwala wyrazić najwaŝniejsze zagadnienia z pominięciem zbędnych szczegółów Precyzyjny Pomaga znaleźć braki oraz niespójności Graficzny Pozwala zilustrować obiekty oraz związki zachodzące między nimi 33

34 Język UML w budowie modeli oprogramowania Modelowanie statyczne opisuje elementy i strukturę wnętrza systemu diagramy klas, obiektów, komponentów i rozmieszczenia Modelowanie funkcjonalności systemu opisuje co nowy system ma robić (lub co robi system istniejący) diagramy przypadków uŝycia Modelowanie dynamiczne - opisuje zachowanie systemu w terminach interakcji elementów systemu - diagramy aktywności, stanów, sekwencji i współdziałania 34

35 Problem: jakie są rzeczywiste wymagania klienta 35

36 InŜynieria wymagań DEFINICJA: systematyczny proces opracowywania wymagań realizowany przez iteracyjną współpracę między procesami: analizy problemu, dokumentowania końcowych obserwacji w postaci róŝnorodnych formatów prezentacji oraz sprawdzania dokładności uzyskanych informacji InŜynieria wymagań jest działalnością, która przekształca potrzeby i Ŝyczenia (zwykle niekompletne i wyraŝone nieformalnie) klienta i potencjalnego uŝytkownika systemu komputerowego w kompletną precyzyjną i spójną specyfikację, i o ile to moŝliwe, zapisaną w formalnej notacji. 36

37 Podsumowanie -Wytwarzanie oprogramowania obejmuje następujące etapy: [modelowanie biznesowe], specyfikowanie wymagań, [analizę] projektowanie, implementację, testowanie i pielęgnację. - Wytworzenie oprogramowania wysokiej jakości wymaga doboru i stosowania metodyki wytwórczej - Język UML jest językiem modelowania i specyfikacji; moŝe być stosowany na wszystkich etapach wytwarzania oprogramowania. - Kompletna specyfikacja wymagań jest kluczowa dla powodzenia przedsięwzięcia wytwórczego. 37