Post on 28-Feb-2019
Literatura
1. Gamma E. i in.: Wzorce projektowe, WNT, Warszawa 2005
2. Jaszkiewicz A.: Inżynieria oprogramowania, Helion, Gliwice 1997
3. Miles R., Hamilton K.: UML 2.0. Wprowadzenie, Helion, Gliwice2007
4. Pressman R. S.: Praktyczne podejście do inżynierii oprogramowania,WNT, Warszawa 2004
5. Sommerville I.: Inżynieria oprogramowania, WNT, Warszawa 2003
6. Wrycza S., Marcinkowski B., Wyrzykowski K.: Język UML 2.0 wmodelowaniu systemów informatycznych, Helion, Gliwice 2006
Inżynieria Oprogramowania 2/36
Plan wykładów
Zagadnienia omawiane na wykładzie:
I Wprowadzenie do inżynierii oprogramowania.I Projektowanie oprogramowania z wykorzystaniem UML.I Zaawansowana inżynieria oprogramowania.I Testowanie oprogramowania.I Metodyka powstawania oprogramowania.I Zarządzanie przedsięwzięciem informatycznym.
Inżynieria Oprogramowania 3/36
Informacje ogólne
I Kontakt:I mail: robert.dyja@icis.pcz.plI strona: http://icis.pcz.pl/˜dyja
I Obecność na wykładach – nie jest wymaganaI Przedmiot kończy się egzaminem pisemnym w formie testu
Inżynieria Oprogramowania 4/36
Rola inżynierii oprogramowania
I Gospodarki wszystkich krajów rozwiniętych polegają naoprogramowaniu.
I Coraz więcej systemów wymaga niezawodnegooprogramowania.
I Inżynieria oprogramowania zajmuje się teorią, metodami inarzędziami związanymi z wytwarzaniem oprogramowania.
I Obecnie wytwarzanie oprogramowania jest poważną gałęziągospodarki narodowej rozwiniętego kraju.
Inżynieria Oprogramowania 5/36
Koszty oprogramowania
I Koszty oprogramowania są często dominującym składnikiemkosztów całego systemu. Zdarza się, że koszt oprogramowaniaznacznie przekracza samą wartość sprzętu komputerowego np.komputera osobistego.
I Koszt utrzymania i konserwacji oprogramowania jest większyniż koszt jego wytworzenia. Wieloletnia konserwacjaoprogramowania może kosztować wielokrotnie więcej niż jegozakup.
I Inżynieria oprogramowania zajmuje się efektywnymi metodamiwytwarzania i implementowania oprogramowania.
Inżynieria Oprogramowania 6/36
Definicja oprogramowania
I Oprogramowanie to programy komputerowe, cała związana znimi dokumentacja i dane konfiguracyjne.
I Rodzaje produktów oprogramowania:I powszechne – sprzedawane na wolnym rynku,I dostosowane – wykonywane na zamówienie.
Inżynieria Oprogramowania 7/36
Charakterystyczne cechy oprogramowania
I Oprogramowanie przetwarza informacje.I Rola oprogramowania znacznie wzrosła w ciągu ostatnich 50
lat.I Oprogramowanie jest wytwarzane, ale nie jest fizycznie
konstruowane tak jak sprzęt.I Nie występuje etap fizycznego konstruowania oprogramowania.I Większość kosztów związanych z tworzeniem oprogramowania
ponosi się na etapie projektowania.
Inżynieria Oprogramowania 8/36
Charakterystyczne cechy oprogramowania – cd.
Oprogramowanie się nie zużywa
Czas
Zużycie
Błędymłodości
Zużycie
Rysunek: Krzywa awaryjnościsprzętu
Czas
Zuż
ycie
Krzywa idealna
Krzywa rzeczywista
Zmiana
Zwiększenie awaryjności spowodowane zmianami
Rysunek: Krzywa awaryjnościoprogramowania
Inżynieria Oprogramowania 9/36
Charakterystyczne cechy oprogramowania – cd.
I Chociaż firmy komputerowe coraz chętniej korzystają zkomponentów dostarczonych przez innych producentów, tojednak większość swoich produktów tworzą od podstaw.I Każda dziedzina inżynierii posiada standardowe rozwiązania.I Już w latach 60–tych XX wieku powstały pierwsze biblioteki
podprogramów.
Inżynieria Oprogramowania 10/36
Dziedziny zastosowań oprogramowania
I Oprogramowanie systemoweI Systemy czasu rzeczywistegoI Systemy informacyjne dla przedsiębiorstwI Oprogramowanie inżynierskie i naukoweI Systemy wbudowaneI Oprogramowanie komputerów osobistychI Oprogramowanie internetowe
Inżynieria Oprogramowania 11/36
Właściwości dobrego oprogramowania
I Konkretny zbiór właściwości zależy od zastosowania, niemniejmożna podać ogólny zbiór właściwości.
I Zdolność do pielęgnacjiI Zdolność do ewolucji zgodnie z potrzebami klientów
I NiezawodnośćI Nie powinno powodować fizycznych lub ekonomicznych
katastrof w przypadku awariiI Efektywność
I Nie powinno marnotrawić zasobów systemu takich jak pamięćczy czas procesora
I UżytecznośćI Powinno być użyteczne, bez zbędnego wysiłku ze strony
użytkownika (np. interfejsy)
Inżynieria Oprogramowania 12/36
Kryzys oprogramowania
I Porażki zyskują znacznie większą uwagę niż sukcesy.I Kryzys oprogramowania przewidziany już 50 lat temu dotąd
nie nastąpił.I Kłopoty związane z tworzeniem oprogramowania nie dotyczą
tylko problemów z nie funkcjonującymi jak należyprogramami, ale przede wszystkim z ich prawidłowymtworzeniem i dalszym utrzymywaniem.
Inżynieria Oprogramowania 13/36
Mity związane z tworzeniem oprogramowania
Mity kierownictwa
I Mamy już pełną książkę standardów i procedur postępowania.I Pracownicy mają najlepsze narzędzia pracy, bo pracują na
najnowszych komputerach.I Jeśli prace się opóźniają zawsze można przydzielić do zadania
więcej programistów.I Zlecenie napisania programu innej firmie zwalnia z myślenia o
nim.I Ogólne określenie wystarczy do rozpoczęcia prac. Szczegóły
można dopracować później.I Wymagania wobec systemu wciąż się zmieniają, ale to nie
problem, bo oprogramowanie jest elastyczne i łatwo je zmienić.
Inżynieria Oprogramowania 14/36
Mity związane z tworzeniem oprogramowania
Mity informatyków
I Po napisaniu i uruchomieniu programu praca jest wykonana.I Jedynym wynikiem pracy nad oprogramowaniem jest
działający program komputerowy.I Inżynieria oprogramowania zmusi programistów do tworzenia
przepastnych, zbędnych dokumentów i nieuchronnie spowolnipracę.
Inżynieria Oprogramowania 15/36
Definicja inżynierii oprogramowania
I Jest to dziedzina inżynierii, która obejmuje wszystkie aspektytworzenia oprogramowania od fazy początkowej do jegopielęgnacji,
I Inżynierowie oprogramowania pracują w sposób systematycznyi uporządkowany, ponieważ jest to najskuteczniejszy sposóbtworzenia oprogramowania wysokiej jakości.
Inżynieria Oprogramowania 16/36
Jaka jest różnica pomiędzy inżynieriąoprogramowania a informatyką?
I Zasadniczo informatyka obejmuje teorie i podstawowe zasadydziałania komputerów. Inżynieria oprogramowania obejmujepraktyczne problemy związane z tworzeniem oprogramowania.
I Z jednej strony inżynier programowania powinien znać teorieinformatyczne, z drugiej jednak nie zawsze przystają one dorzeczywistości.
Inżynieria Oprogramowania 17/36
Proces tworzenia oprogramowania
I Jest to zbiór czynności i związanych z nimi wyników, którezmierzają do opracowania produktu programowego.
I Zasadnicze czynności wspólne dla wszystkich procesów:I Specyfikacja oprogramowania,I Tworzenie oprogramowania,I Zatwierdzanie oprogramowania,I Ewolucja oprogramowania.
Inżynieria Oprogramowania 18/36
Metody inżynierii oprogramowania
I Metody inżynierii oprogramowania to uporządkowanepodejście do tworzenia oprogramowania, które obejmuje:
I Opisy modeli systemuI Np. Modele obiektów, modele przepływu itp.
I RegułyI Ograniczenia, którym podlegają modele systemu
I ZaleceniaI Heurystyki, które określają dobre zwyczaje projektantów
I PoradnictwoI Opisy czynności, które należy wykonać
Inżynieria Oprogramowania 19/36
Modele procesu tworzenia oprogramowania
Model procesu tworzenia oprogramowania
I Jest to uproszczona prezentacja procesu tworzeniaoprogramowania. Modele ze swej natury są uproszczeniami.
I Przykłady ogólnych modeli (paradygmatów) tworzeniaoprogramowania:I model kaskadowy,I model oparty na prototypowaniu,I programowanie odkrywcze,I realizacja przyrostowa,I montaż z gotowych elementów,I model spiralny.
Inżynieria Oprogramowania 20/36
Model kaskadowy – zalety i wady
Wady:
I Wysoki koszt błędów popełnionych we wstępnych fazach.I Długa przerwa w kontaktach z klientem.I Narzucenie twórcom oprogramowania ścisłej kolejności
wykonywania prac.
Inżynieria Oprogramowania 22/36
Model oparty na prototypowaniu
Etapy:
I ogólne określenie wymagań,I budowa prototypu,I weryfikacja prototypu przez klienta,I pełne określenie wymagań,I realizacja pełnego systemu zgodnie z modelem kaskadowym.
Inżynieria Oprogramowania 23/36
Model oparty na prototypowaniu – zalety i wady
Zalety:
I lepsze określenie wymagań klienta,I możliwość szybkiej demonstracji pracującej wersji systemu,I możliwość szkoleń zanim zostanie zbudowany pełen system.
Wady:
I dodatkowy koszt budowy prototypu,I konieczność oczekiwania na końcowy system po akceptacji
prototypu.
Inżynieria Oprogramowania 24/36
Metody budowy prototypu
I niepełna realizacja,I języki wysokiego poziomu,I wykorzystanie gotowych komponentów,I szybkie programowanie (ang. quick-and-dirty),I generatory interfejsu użytkownika,I programowanie odkrywcze.
Inżynieria Oprogramowania 25/36
Programowanie odkrywcze
Rysunek: Schemat programowaniaodkrywczego
Wady:
I Niemożliwe zachowaniesensownej strukturysystemu.
I Testowanie tylko przyudziale klienta.
Inżynieria Oprogramowania 26/36
Realizacja przyrostowa – zalety i wady
Zalety:
I Skrócenie przerw w kontaktach z klientem.I Możliwość wczesnego wykorzystania przez klienta
dostarczonych fragmentów systemu.I Możliwość elastycznego reagowania na powstałe opóźnienia.
Wady:
I Dodatkowy koszt związany z niemożnością wydzieleniapodzbioru funkcji niezależnych od pozostałych.
Inżynieria Oprogramowania 28/36
Montaż z gotowych elementów
Jest to wykorzystanie:
I bibliotek,I języków czwartej generacji,I pełnych aplikacji.
Metody pozyskiwania gotowych komponentów:
I zakup od zewnętrznych dostawców,I opracowanie wyników aktualnie realizowanych przedsięwzięć
tak, aby mogły być wykorzystane w kolejnychprzedsięwzięciach.
Inżynieria Oprogramowania 29/36
Montaż z gotowych elementów – zalety i wady
Zalety:
I wysoka niezawodność,I zmniejszenie ryzyka,I efektywne wykorzystanie specjalistów,I narzucenie standardów,I potencjalna redukcja kosztów.
Wady:
I dodatkowy koszt przygotowania elementów do ponownegowykorzystania,
I ryzyko uzależnienia się od dostawcy komponentów,I niedostatki narzędzi wspomagających ten rodzaj pracy.
Inżynieria Oprogramowania 30/36
Model spiralny
Planowanie
Atestowanie
Analizaryzyka
Konstrukcja
Rysunek: Model spiralny Inżynieria Oprogramowania 31/36
CASE ang.(Computer-Aided Software Engineering)
I CASE obejmuje rożne programy wykorzystane dowspomagania czynności procesu tworzenia oprogramowania(np. edytory notacji, generatory kodów).
I upper-CASEI Związane z początkowymi fazami tworzenia oprogramowania.
I lower-CASEI Wspomagają implementację i testowanie.
Inżynieria Oprogramowania 32/36
Najistotniejsze wyzwania dla inżynierówoprogramowania
I Wyzwanie dziedzictwaI Pielęgnacja i modyfikacja działających dużych systemów,
pełniących poważne funkcje gospodarczeI Wyzwanie różnorodności
I Wymóg działania oprogramowania w systemach rozproszonychprzy rożnych typach komputerów i systemów wspomagających
I Wyzwanie doręczeniaI Wymóg dostarczanie gotowego programowania w skróconym
czasie bez utraty jakości
Inżynieria Oprogramowania 33/36
Zasady zawodowej odpowiedzialności
I Zachowywanie tajemnicyI Inżynierowie powinni zawsze dochowywać tajemnic
powierzonych przez pracodawców i klientów, niezależnie odtego czy podpisano formalną umowę o ochronie tajemnicy.
I KompetencjeI Inżynierowie nie powinni zawyżać poziomu swoich kompetencji.
Nie powinni świadomie przyjmować prac, które przekraczająich możliwości.
Inżynieria Oprogramowania 34/36
Zasady zawodowej odpowiedzialności
I Prawo własności intelektualnejI Inżynierowie powinni znać miejscowe prawo regulujące
korzystanie z własności intelektualnej. Powinni szczególniedbać o poszanowanie intelektualnej własności swoichpracodawców i klientów.
I Niewłaściwe użycie komputeraI Inżynierowie oprogramowania nie powinni używać swoich
umiejętności do niewłaściwego używania cudzych komputerów.Niewłaściwe użycie może być dość banalne (np. granie namaszynie pracodawcy) lub skrajnie poważne (rozsiewaniewirusów).
Inżynieria Oprogramowania 35/36