Inynieria oprogramowania Wykład 1 Prowadzcy Wprowadzenie do inynierii oprogramowania Bartosz Walter <Bartek.Walter@man.poznan.pl> dr in. Bartosz Walter Instytut Informatyki PP Pokój: Centrum Polsko-Niemieckie p. 2 Email: Bartosz.Walter@cs.put.poznan.pl WWW: http://www.se.cs.put.poznan.pl/ Agenda Rynek oprogramowania Historia i geneza inynierii oprogramowania Rola inynierii Aspekty inynierii oprogramowania Plan wykładów wiat 207 miliardów euro (USA 97 miliardów, UE 63 miliardy) Bez oprogramowania wytwarzanego na własne potrzeby Wzrost 5.1% rocznie + 125 miliardów euro dodatkowych usług W UE 60-70% oprogramowania jestwytwarzane w firmach, dla których nie jest to główn działalnoci Historia: pocztki Historia: rozwój Sprzt o bardzo ograniczonych moliwociach Ograniczone zastosowania Małe programy Programy pisane czsto dla własnych potrzeb lub potrzeb dobrze znanych osób Dobrze wyspecyfikowane zadania Nowy zawód: programista Nowa rewolucja przemysłowa (Osborne 1979) Specjalizowane jzyki programowania COBOL, Fortran, Algol Sprzt o duo wikszych moliwociach, np. pami wirtualna, pami masowa, czytniki kart i tam Nowe, poza naukowe i poza militarne zastosowania np. w biznesie Próba realizacji wielu duych przedsiwzi programistycznych Extreme Programming Modified 1
Objawy kryzysu oprogramowania Historia: kryzys oprogramowania Rozwój technik wytwarzania oprogramowania nie nada za rozwojem sprztu komputerowego i potrzeb klientów Metody tworzenia oprogramowania si nie skaluj Czy kryzys oprogramowania trwa do dzisiaj? Nadal wikszo przedsiwzi przekracza czas i/lub budet Około 25% przedsiwzi programistycznych nie jest koczona 90% firm przyznaje, e do czsto zdarzaj im si opónienia przedsiwzi Powszechna akceptacja kiepskiej jakoci oprogramowania (w pewnych obszarach) Brak powszechnie akceptowanych i stosowanych standardów Przyczyny kryzysu Historia: próby przełamania kryzysu Dua złoono systemów informatycznych Złoono, zmienno, nieadekwatno wymaga Niepowtarzalno poszczególnych przedsiwzi Nieprzejrzysto procesu budowy oprogramowania Pozorna łatwo wytwarzania i modyfikowania oprogramowania Potrzeba kreatywnoci Czynnik ludzki Mało wymagajcy rynek (?) Niedoskonało narzdzi Brak standaryzacji 1968: konferencja NATO w Ga-Pa nt. inynierii oprogramowania Metodyki strukturalne Metodyki obiektowe Technologie komponentowe Programowanie aspektowe Standaryzacja technologii Kryzys czy chroniczne niedomaganie? Time to Market Czym jest inynieria oprogramowania? Oprogramowanie Inynieria oprogramowania dotyczy tworzenia duych systemów informatycznych przez wiele osób Inynieria oprogramowania to wiedza techniczna, dotyczca wszystkich faz cyklu ycia oprogramowania, której celem jest uzyskanie wysokiej jakoci produktu oprogramowania. Inynieria oprogramowania: zastosowanie systematycznego, zdyscyplinowanego, policzalnego podejcia do tworzenia, wykorzystywania i utrzymania oprogramowainia. Inynieria oprogramowania = proces + metody zarzdcze i techniczne + narzdzia Oprogramowanie jest budowane lub rozwijane w sposób inynierski (zdefiniowany, uporzdkowany), jednak w zupełnie inny ni w innych dziedzinach inynierii Oprogramowanie si nie zuywa, cho jego jako si pogarsza Cho przemysł skłania si ku tworzeniu oprogramowania z komponentów i reuywalnoci, to jednak wikszo systemów jest dedykowana Extreme Programming Modified 2
Modele procesu tworzenia oprogramowania Model klasyczny wodospadowy Zamknicie jednej fazy otwiera nastpn Prototypowanie Pierwszy wstpny prototyp (działajcy!), potem właciwa implementacja Programowanie odkrywcze Programici odgaduj potrzeby klienta Model przyrostowy Kolejne funkcje s implementowane stopniowo Model klasyczny (wodospad( wodospad) czas Wymagania Analiza Projekt Implementacja Testowanie Model klasyczny (wodospad( wodospad) Wady i zalety modelu wodospadowego Wymuszona niezmienno wymaga Wysoki koszt błdów popełnionych we wstpnych fazach Koszt błdu w wymaganiach 100-1000 razy wikszy od kosztu błdu programistycznego! Długa przerwa w kontaktach z klientem Nie lubiany przez wykonawców Wysze prawdopodobiestwo niepowodzenia w przypadku duych przedsiwzi Łatwo zarzdzania planowanie i monitorowanie Prototypowanie Cel lepsze okrelenie wymaga Fazy: Ogólne okrelenie wymaga. Budowa prototypu. Weryfikacja prototypu przez klienta. Pełne okrelenie wymaga. Realizacja nowego, pełnego systemu zgodnie z modelem kaskadowym. Wady i zalety prototypowania Zmniejszone ryzyko popełnienia błdu podczas definiowania wymaga i analizy Szybka prezentacja klientowi działajcego szkieletu aplikacji (szybka reakcja) Dodatkowy koszt wytworzenia prototypu Moliwo nieporozumienia z klientem Extreme Programming Modified 3
Model spiralny (B. Boehm) Wady i zalety modelu spiralnego funkcjonalno czas Planowanie Analiza wymaga i ryzyka Moliwo zmiany wymaga w trakcie realizacji systemu Szybka reakcja klienta na pojawiajce si zmiany Niektóre funkcje s dostpne przed zakoczeniem przedsiwzicia Integracja! Zarzdzanie! Wdroenie i ocena uytkownika Projektowanie i budowa Składowe inynierii oprogramowania Wymagania Analiza Testowanie Proces Wdroenie Szkolenia Szacowanie Projektowanie Planowanie Inynieria oprogramowania Zarzdzanie przedsiwziciem Wersjonowanie Kontrola i nadzór Modelowanie Reinynieria Pomiary Raportowanie Modelowanie Modelowanie: odtwarzanie rzeczywistoci w celu uchwycenia najwaniejszych elementów i pomijanie rzeczy nieistotnych Elementami modelu s elementy rzeczywistoci Modelowanie procesów a modelowanie danych Dekompozycja strukturalna Modelowanie obiektowe (UML): obiekty, relacje, atrybuty Jako Zarzdzanie ryzykiem Dokumentowanie Projektowanie Reprezentacja modelu uwzgldniajca ograniczenia techniczne i sposób realizacji Ten sam model moe by zaprojektowany na róne sposoby Elementami projektu s byty implementacyjne Projektowanie strukturalne vs. Obiektowe Pojcia: abstrakcja, uszczegółowienie, modularno, architektura, hermetyzacja Projektowanie klas, relacji, interfejsów... Testowanie Błdów nie mona całkowicie wyeliminowa Testowanie jest czynnoci destrukcyjn Dobry test to test, który z duym prawdopobiestwem pozwala wykry błd Skuteczny test to test, który znajduje nowy błd Testowanie a model tworzenia oprogramowania Dobór danych testowych i obszaru testowania Zasada Pareto Skalowalno od szczegółu do ogółu Niezaleno testowania od tworzenia oprogramowania Extreme Programming Modified 4
Testowanie: : zadanie int oblicz(int arg1, int arg2, int operacja) { } switch (operacja) { } case DODAWANIE: return arg1 + arg2; case ODEJMOWANIE: return arg1 arg2; case MNO ENIE: return arg1 * arg2; case DZIELENIE: return arg1 / arg2; default: return 1; Szacowanie Czy przedsiwzicie jest wykonalne? Czas = pienidz Dekompozycja Funkcjonalna Produktowa Modele Punkty funkcyjne COCOMO II PROBE Dokumentowanie Programy yj dłuej ni pami twórców Spójno artefaktów (automatyzacja?) Dokumentacja uytkowa a dokumentacja techniczna Jzyk i psychologia Dokumentowanie kosztuje... Nikt nie lubi dokumentowania, ale dobrze gdy dokumentacja istnieje Planowanie Zasoby Czas Ludzie Narzdzia Materiał (komponenty) Zadania i ich przydział Harmonogramy Czy przedsiwzicie jest wykonalne? Wersjonowanie i zarzdzanie zmian Zmiany s nieuniknione Jaka wersja modułu X posiadała funkcj A? Identyfikacja elementów i ich wersji Spójno wersji a praca w zespole Wiele wersji jednego oprogramowania Formalne zatwierdzanie zmian Pomiary Potrzeba ilociowej informacji nt. produktu i procesu Informacja zarzdcza nie mona sterowa niczym, czego nie mona zmierzy Dane historyczne, teraniejszo i przyszło Rodzaje metryk Produktowe: rozmiar, złoono komponentów, liczba interfejsów, ekranów, formatek, stron dokumentacji, liczba wykrytych błdów Procesowe: czas, koszt, opónienie, stopie zrównoleglenia, liczba wymaga, czas powicony na testowanie Extreme Programming Modified 5
Reinynieria Nieustanny pd ku lepszemu Zmiana fundamentów w czasie eksploatacji Oblicza zmian Zmiana procesu Zmiana funkcjonalnoci Zmiana kodu (refaktoryzacja) Koszt pielgnacji = 80% TCO Inynieria odwrotna: odtwarzanie projektu na podstawie programu Plan I sem. Modelowanie (UML) Projektowanie (design patterns) Programowanie w jzyku Java Testowanie (scenariusze, Junit) Szacowanie (PROBE, Cocomo II) Dokumentowanie (uytkowe i techniczne) Zarzdzanie zmian i wersjonowanie Pomiary Narzdzia Readings Q & A 1. Jaszkiewicz A., Inynieria oprogramowania. Helion 1997. 2. Górski J., Inynieria oprogramowania w projekcie informatycznym. Mikom 2000. 3. Fowler M., UML w kropelce. Mikom 2001. 4. Szejko St. (red.), Metody wytwarzania oprogramowania. Mikom 2002. 5. Pressman R., Software Engineering. A Practitioner s Approach. McGraw Hill 2001. 6. Sommerville I., Software Engineering. Addison-Wesley 1995. Extreme Programming Modified 6