inżynieria oprogramowania - k.bartecki.po.opole.pl fileinżynieria oprogramowania to wiedza...
TRANSCRIPT
prowadzący: dr hab. inż. Krzysztof Bartecki, prof. PO
www.k.bartecki.po.opole.pl
In ż ynieria oprogramowania
wykład I – wprowadzenie
K. Bartecki, Inżynieria oprogramowania, I/2
Kierunek Informatyka, studia stacjonarne
Semestr 4: Inżynieria oprogramowania I (5 punktów ECTS)
● 30 godzin wykładu + egzamin,
● 15 godzin projektu.
Semestr 5: Inżynieria oprogramowania II (2 punkty ECTS)
● 30 godzin ćwiczeń laboratoryjnych (w tym projekt systemu
informatycznego).
Kierunek Informatyka, studia niestacjonarne
Semestr 5: Inżynieria oprogramowania (5 punktów ECTS)
● 20 godzin wykładu + egzamin,
● 20 godzin ćwiczeń laboratoryjnych (w tym projekt systemu
informatycznego),
K. Bartecki, Inżynieria oprogramowania, I/3
Czym zajmuje się
inżynieria oprogramowania ?
Zajmuje się wszelkimi aspektami produkcji oprogramowania:
● od analizy i określenia wymagań,
● przez projektowanie i wdrożenie,
● aż do ewolucji gotowego oprogramowania.
stanowi zbiór umiejętności, pojęć i procedur, mających pomóc ludziom
dobrze wykonywać pracę przy tworzeniu oprogramowania.
Inżynieria oprogramowania – próba definicji
Inżynieria oprogramowania to wiedza techniczna, dotycząca
wszystkich faz cyklu życia oprogramowania, której celem jest uzyskanie
wysokiej jakości produktu – czyli oprogramowania.
Zgodnie z tą definicją, oprogramowanie to produkt taki, jak każdy inny,
a więc powinno ono być:
● zgodne z wymaganiami i oczekiwaniami użytkownika,
● niezawodne,
● efektywne,
● łatwe w konserwacji,
● ergonomiczne.
Inżynieria oprogramowania – inna definicja
K. Bartecki, Inżynieria oprogramowania, I/4
Inżynieria oprogramowania obejmuje m.in. następujące zagadnienia:
● sposoby prowadzenia przedsięwzięć programistycznych,
● techniki planowania, szacowania kosztów, harmonogramowania
i monitorowania przedsięwzięć programistycznych,
● metody analizy i projektowania systemów,
● techniki zwiększania niezawodności oprogramowania,
● sposoby testowania systemów i szacowania niezawodności,
● sposoby przygotowania dokumentacji,
● konserwacja oprogramowania, które powstało wiele lat temu i ciągle
jest w użyciu,
● metody redukcji kosztów konserwacji oprogramowania.
Zakres inżynierii oprogramowania
K. Bartecki, Inżynieria oprogramowania, I/5
Dlaczego inżynieria oprogramowania
jest ważna ?
● Szybka i dokładna produkcja wielu nowoczesnych produktów
wymaga niezawodnego oprogramowania,
● gospodarki wszystkich rozwiniętych krajów świata zależą od
oprogramowania,
● wytwarzanie oprogramowania jest poważną gałęzią
gospodarki narodowej rozwiniętych krajów.
K. Bartecki, Inżynieria oprogramowania, I/6
K. Bartecki, Inżynieria oprogramowania, I/7
Dzięki inżynierii oprogramowania możliwe stało się m.in. zaplanowanie
oraz implementacja oprogramowania złożonego z wielu milionów linii
kodu, przeznaczonego dla nowego Airbusa A380
…ale można spotkać również
inne opinie !
K. Bartecki, Inżynieria oprogramowania, I/8
"Software Engineering" is a myth and only losers use it. You can be a
perfectly good and productive developer without learning "Software
Engineering". Learn development by doing development, not reading
about it. If you're in a large team, just use commonsense, good
communication and be nice to everybody.
All what is written about "Software Engineering" is hype and
charlatanism. Use your own brain and experience and forget about all
that "Software Engineering Enterprise OOP Patterns Domain DSL
Modelling" bullshit. If anything, study abstract algebra; at least you'll
have a fundamental understanding of the powers of abstraction and
generalization.
[jedna z opinii na forum http://stackoverflow.com/]
● 1950-60 – drobne oprogramowanie przeznaczone głównie dla celów
naukowych,
● 1960-80 – liczniejsze zastosowania komputerów – rozwój języków
programowania wyższego poziomu,
● od 1980 – gwałtowny rozwój sprzętu i znaczne zwiększenie jego
możliwości – próby nadążenia z oprogramowaniem – kompletne
fiasko.
Wielu przedsięwzięć informatycznych nie zakończono ze względu
na ich zbyt wielką złożoność, bądź też ze względu na przekroczenie
założonego czasu lub budżetu.
Historia rozwoju oprogramowania
K. Bartecki, Inżynieria oprogramowania, I/9
K. Bartecki, Inżynieria oprogramowania, I/10
Historia rozwoju inżynierii oprogramowania – c.d.
1950-1960
lata
1960-1970
1970-1990
od 1990
programy pisane przez
programistów dla siebie,
komputery w nauce
zakres
oprogramowania błędy
Inżynieria
oprogramowania
duże programy
i pierwsze narzędzia
przetwarzania informacji
olbrzymie systemy
informatyczne –
komputery „dla mas”
drobne błędy
bez większych
konsekwencji
dość duża cena za
brak przemyśleń w
tworzeniu oprogram.
kryzys
oprogramowania
indywidualna -
programisty
początki inżynierii
oprogramowania –
„rzemiosło”
rozwój inżynierii
oprogramowania
rozkwit inżynierii
oprogramowania wszechobecne
kryzys
oprogramowania –
próby eliminacji
Kryzys oprogramowania
– polega na tym, że rozwój technik wytwarzania oprogramowania
nie nadąża za rozwojem sprzętu komputerowego.
Główne przejawy kryzysu oprogramowania:
● projekty informatyczne przekraczają założony budżet finansowy,
● projekty informatyczne przekraczają założony harmonogram czasowy,
● oprogramowanie jest niskiej jakości,
● oprogramowanie nie spełnia wymagań użytkownika.
Kryzys oprogramowania trwa do dziś!
K. Bartecki, Inżynieria oprogramowania, I/11
Przyczyny kryzysu oprogramowania:
● duża złożoność systemów informatycznych,
● niepowtarzalność poszczególnych przedsięwzięć,
● trudność w ocenie stopnia zaawansowania prac:
„jeżeli po miesiącu realizacji projektu informatycznego usłyszymy od
programistów, że prace są zaawansowane w 90%, to można się
spodziewać, że przedsięwzięcie potrwa jeszcze cały rok”,
● pozorna łatwość wytwarzania oprogramowania
(założenie liniowości w procesie tworzenia kodu):
„to, że w ciągu jednego dnia napisaliśmy i przetestowaliśmy program
liczący 100 linii nie oznacza, że w ciągu 100 dni opracujemy program
liczący 10 000 linii”
K. Bartecki, Inżynieria oprogramowania, I/12
K. Bartecki, Inżynieria oprogramowania, I/13
„Główną przyczyną kryzysu oprogramowania jest fakt,
że moc obliczeniowa współczesnych komputerów jest
o kilkanaście rzędów wielkości większa niż kiedyś!
Gdy nie było komputerów, nie było problemu ich oprogramowania;
gdy pojawiło się kilka słabych maszyn,
ich programowanie było umiarkowanym problemem;
teraz zaś mamy do dyspozycji gigantyczne komputery,
więc również ich oprogramowanie stało się równie gigantycznym
problemem!”
Edsger Wybe Dijkstra (1930-2002)
holenderski naukowiec, pionier informatyki
1962 – Zaraz po starcie rakieta
Mariner 1, której planowanym celem
była planeta Wenus, zbacza z kursu i
zostaje zniszczona.
Powód: pominięty na etapie
odręcznego przepisywania równań
znak kreski oznaczającej funkcję
„wygładzania” prędkości rakiety.
Wniosek:
"No detail is too small to overlook"
„Żaden szczegół nie jest zbyt mały,
aby go przeoczyć”
K. Bartecki, Inżynieria oprogramowania, I/14
Katastrofy oprogramowania
K. Bartecki, Inżynieria oprogramowania, I/15
1971 – Francuski satelita Eole 1 doprowadza do zniszczenia 72 balonów
meteorologicznych.
Powód: wezwanie do wysyłania danych pomiarowych software
zinterpretował jako rozkaz autodestrukcji.
K. Bartecki, Inżynieria oprogramowania, I/16
1978 – Satelita Nimbus 7 zignorował dziurę ozonową nad Antarktydą.
Powód: oprogramowanie analizujące traktowało wartości zbyt odbiegające
od normy jako błędy i korygowało je.
K. Bartecki, Inżynieria oprogramowania, I/17
1979 – Pięć amerykańskich reaktorów jądrowych zostało wyłączonych,
gdyż program określający prawdopodobieństwo trzęsień ziemi dostarczał
błędnych wartości.
Powód: program wyliczał sumę zamiast pierwiastka z sumy kwadratów.
K. Bartecki, Inżynieria oprogramowania, I/18
1982 – Brytyjski niszczyciel HMS Sheffield został trafiony rakietą podczas
wojny na Falklandach i zatonął. Zginęło 20 marynarzy.
Powód: przed uderzeniem oprogramowanie samoczynnie przełączyło
system obrony statku w tryb "Safe".
K. Bartecki, Inżynieria oprogramowania, I/19
1985-1987 – Urządzenie do naświetlania Therac 25 zabija pacjentów,
aplikując im zbyt duże dawki promieniowania.
Powód: oprogramowanie potrafiło tylko wtedy przetwarzać bezbłędnie
wiele wątków, gdy operator wydawał polecenia powoli.
K. Bartecki, Inżynieria oprogramowania, I/20
1996 – nieudany start rakiety Ariane 5 (lot 501)
Przyczyna: użycie niezmienionego oprogramowania z rakiety Ariane 4.
Stary, 16-bitowy moduł nie był w stanie konwertować dużo większej niż
w poprzednim modelu rakiety prędkości jej wznoszenia się do wartości
całkowitej.
Skutek: przepełnienie pamięci, nadpisywanie innych zmiennych sytemu,
awaria systemu nawigacyjnego, rozbicie rakiety.
K. Bartecki, Inżynieria oprogramowania, I/21
1987 – Krach na giełdzie wywołuje spadek głównego indeksu o 22,6 %
(500 miliardów $).
Jeden z powodów: program giełdowy nie był w stanie obsługiwać
zamówień kupujących, co doprowadziło do panicznej wyprzedaży.
K. Bartecki, Inżynieria oprogramowania, I/22
1988 – Irański Airbus (lot 655)
zostaje zestrzelony przez
amerykański krążownik USS
Vincennes – ginie 290 osób.
Powód: zainstalowany na statku,
wart 400 000 $, system Aegis
(Egida) uznał Airbusa za
atakujący go irański samolot
bojowy.
1999 – Sonda Mars Climate Orbiter
spala się w marsjańskiej atmosferze.
Powód: instrumenty mierzyły siły
w funtach, a oprogramowanie z NASA
operowało jednostkami SI, niutonami (!)
K. Bartecki, Inżynieria oprogramowania, I/23
K. Bartecki, Inżynieria oprogramowania, I/24
1999 – Sonda Mars Polar Lander uderza o powierzchnię Marsa
z prędkością 80 km/h i rozbija się.
Powód: oprogramowanie sterujące zinterpretowało wysunięcie się odnóży
lądowniczych jako dotknięcie podłoża i wyłączyło silnik.
K. Bartecki, Inżynieria oprogramowania, I/25
1990 – Nowe oprogramowanie amerykańskiej firmy telekomunikacyjnej
AT&T zmusza prawie wszystkie centrale w USA do wyzerowania się –
przez 9 godzin nie była możliwa żadna rozmowa.
Powód: błędnie wstawiona instrukcja języka C++ „break”.
K. Bartecki, Inżynieria oprogramowania, I/26
2003 – Na skutek przeciążenia sieci energetycznej 50 milionów
gospodarstw domowych w USA i Kanadzie zostało bez prądu.
Powód: zawiodła funkcja alarmu w programie do zarządzania energią.
K. Bartecki, Inżynieria oprogramowania, I/27
2005 – Odrzutowiec Airbus A380 kosztuje około 5 miliardów euro więcej
i zostaje później oddany do użytku.
Powód: konstruktorzy używali do projektowania różnych wersji
oprogramowania CAD CATIA – z tego powodu wynikły problemy
z okablowaniem samolotu (około 500 km kabli).
K. Bartecki, Inżynieria oprogramowania, I/28
2004 – Stutysięczny bezrobotny, klient niemieckiego programu Hartz IV,
nie otrzymuje pieniędzy.
Powód: program uzupełnia numery kont zerami z niewłaściwej strony.
2009 – System komputerowy francuskiego banku BNP Paribas rozdaje
wielu klientom pieniądze, wykonując wielokrotnie 600 000 transakcji.
Powód: do tej pory nie został ujawniony.
K. Bartecki, Inżynieria oprogramowania, I/29
2008 – samolot McDonnell Douglas MD-82, lot linii Spanair numer 5022
rozbił się tuż po wystartowaniu z madryckiego lotniska w 2008 roku,
zginęły 154 osoby.
Powód: naziemny system komputerowy wykorzystywany do wykrywania
problemów technicznych w samolocie został zainfekowany wirusem typu
trojan. Infekcja uszkodziła system, który nie wyświetlał ostrzeżeń na
temat trzech problemów technicznych, które uniemożliwiłyby obsłudze
naziemnej wydanie zezwolenia na start maszyny.
Wniosek:
błędy w oprogramowaniu to norma
Nawet w dobrze przetestowanych
i często usprawnianych programach znajdują się błędy w kodzie.
Typowe źródła błędów [wg W. Soczyńskiego]:
● błąd w kodzie, spowodowany przez roztargnionego, zmęczonego
(lub poganianego) programistę,
● błąd niezrozumienia kodu – programista, dostając kod po kimś
innym lub wracając do swojego starego kodu, nie wie lub nie
pamięta „o co w nim chodzi”,
● błąd projektowania – nieprzemyślana architektura systemu,
● błędy komunikacji – niezrozumienie między klientem, kierownikiem
projektu a programistą,
● błąd w oszacowaniu czasu trwania projektu.
K. Bartecki, Inżynieria oprogramowania, I/30
Narzędzia CASE
Eliminacja błędów w oprogramowaniu
możliwa jest (w pewnym zakresie) dzięki
wykorzystaniu odpowiednich narzędzi CASE.
K. Bartecki, Inżynieria oprogramowania, I/31
CASE (ang. Computer-Aided Software Engineering, Computer-Aided
Systems Engineering) – to zbiorcza nazwa oprogramowania, używanego
do komputerowego wspomagania projektowania oprogramowania.
CASE
Upper CASE
Lower CASE
Integrated CASE
Podział narzędzi CASE
● Upper-CASE – wspomagają pierwsze fazy budowy systemu –
analizę funkcjonalną i procesową, modelowanie funkcji, procesów,
obiektów. Umożliwiają tworzenie diagramów projektowych.
● Lower-CASE – wspomagają implementację oprogramowania –
np. tworzenie bazy danych, tworzenie i generowanie kodu oraz
testowanie systemu.
● Integrated-CASE – systemy łączące Upper- i Lower-CASE.
K. Bartecki, Inżynieria oprogramowania, I/32
Typowe składniki (moduły) narzędzi CASE
● Słownik Danych (Repozytorium) – baza danych o tworzonym
systemie wraz z narzędziami edytującymi, zarządzającymi
i wyszukującymi te dane.
● Edytor Notacji Graficznych – program graficzny, umożliwiający
tworzenie i edycję diagramów dla faz określania wymagań
systemu, analizy i projektowania.
● Moduł Kontroli Poprawności – narzędzie do wykrywania i
poprawiania błędów w diagramach i repozytoriach.
● Moduł Kontroli Jakości – narzędzie do oceny pewnych
ustalonych miar jakości projektu – np. stopnia złożoności lub
powiązań składowych modelu.
● Generator Raportów – narzędzie tworzące dowolny raport na
podstawie danych z repozytorium.
● Generator Kodu – narzędzie transformujące projekt na szkielet
kodu w wybranym języku programowania.
K. Bartecki, Inżynieria oprogramowania, I/33
Typowe składniki narzędzi CASE – c.d.
● Generator Dokumentacji Technicznej – generator dokumentów
zawierających specyfikację, opisy faz projektu, diagramy oraz
wybrane raporty.
● Moduł Projektowania Interfejsu Użytkownika – narzędzie do
projektowania menu, okien dialogowych oraz innych elementów
interfejsu użytkownika.
● Moduł Inżynierii Odwrotnej – narzędzie pozwalające odtworzyć
słownik danych lub/oraz diagramy na podstawie kodu źródłowego
lub struktury bazy danych.
● Moduł Importu/Eksportu Danych – narzędzie służące do
wymiany danych z innymi narzędziami CASE lub z innymi
programami.
● Moduł Zarządzania Pracą Grupową – narzędzie umożliwiające
współpracę grupy osób podczas pracy nad projektem.
K. Bartecki, Inżynieria oprogramowania, I/34
Przykładowe wolne narzędzia CASE
● Eclipse – otwarte środowisko programistyczne dla Javy, które za
pomocą platformy Eclipse może posłużyć do budowania
oprogramowania wykorzystując język modelowania obiektowego
UML. Posiada także generator kodu.
● NetBeans – otwarty projekt zawierający wiele narzędzi
wspomagających tworzenie oprogramowania. Dodatkowo
umożliwia modelowanie w UML oraz użycie schematów XML.
● StarUML – otwarta, dostępna na zmodyfikowanej licencji GPL
platforma dla systemu Windows, która umożliwia import
projektów z takich komercyjnych aplikacji jak Rational Rose czy
Borland Together. Zapewnia forward- i reverse-engineering kodu w
Javie, C# i C++.
● Umbrello UML Modeller – darmowy program komputerowy
służący do tworzenia diagramów w języku UML, dostępny dla
systemów typu Unix.
K. Bartecki, Inżynieria oprogramowania, I/35
Przykładowe komercyjne narzędzia CASE
● Borland Together – rodzina programów integrujących środowisko
IDE Javy z narzędziami do UMLa. Posiada m.in. funkcje
modelowania danych, szablony kodu, generator dokumentacji, czy
też moduł weryfikacji kodu.
● Enterprise Architect – profesjonalne narzędzie, działające na
platformach Windows i Linux. Obsługuje język UML.
● IBM Rational Rose – jedno z najstarszych, profesjonalnych
narzędzi CASE. Bardzo rozbudowane, obsługuje UML.
● Oracle Designer stanowi zintegrowane narzędzie do projektowania
aplikacji pracujących w środowisku klient/serwer oraz w
architekturze trójwarstwowej.
● PowerDesigner firmy Sybase posiada funkcje umożliwiające m.in.
modelowanie danych oraz procesów, modelowanie obiektowe w
oparciu o standard UML, modelowanie procesów biznesowych.
K. Bartecki, Inżynieria oprogramowania, I/36
Wybrane pozycje literaturowe
z zakresu inżynierii oprogramowania
● Barker R.: Modelowanie związków encji. WNT Warszawa, 1996.
● Barker R., Longman C.: Modelowanie funkcji i procesów. WNT
Warszawa, 1996.
● Beynon-Davies P.: Inżynieria systemów informacyjnych. WNT
Warszawa, 1999.
● Booch G., Rumbaugh J., Jacobson I.: UML – Przewodnik
użytkownika. WNT Warszawa, 2000.
● Chabik J.: Praktyka skutecznego programowania. Wydawnictwo
Nakom Poznań, 1999.
● Coad P., Yourdon E. : Analiza obiektowa. Wydawnictwo Read Me,
Warszawa 1994.
● Dąbrowski W. i inni: Modelowanie systemów informatycznych w
języku UML 2.1 w praktyce. PWN Warszawa, 2007.
K. Bartecki, Inżynieria oprogramowania, I/37
Wybrane pozycje literaturowe
z zakresu inżynierii oprogramowania – c.d.
● Dumnicki R., Kasprzyk A., Kozłowski M.: Analiza i projektowanie
obiektowe. Wydawnictwo Helion, Gliwice 1998.
● Fowler M., Scott K.: UML w kropelce. LTP, Warszawa, 2002.
● Fuglewicz P., Stąpor K., Trojnar A. (1996): CASE dla ludzi,
Wydawnictwo Lupus, Warszawa, 1996.
● Górski J. (red.): Inżynieria oprogramowania w projekcie
informatycznym. MIKOM, Warszawa 1999.
● Jaszkiewicz A. : Inżynieria oprogramowania. Wydawnictwo Helion,
Gliwice 1996.
● Płaczek B.: Techniki projektowania baz danych w środowisku
PowerDesigner. Wydawnictwo PŚ, Gliwice 2010.
● Poźniak-Koszałka I.: Relacyjne bazy danych w środowisku Sybase.
Modelowanie, projektowanie, aplikacje. OW Politechniki
Wrocławskiej, 2004.
K. Bartecki, Inżynieria oprogramowania, I/38
Wybrane pozycje literaturowe
z zakresu inżynierii oprogramowania – c.d.
● Robertson J.: Pełna analiza systemowa. WNT Warszawa, 1999.
● Sinan Si Alhir: UML. Wprowadzenie. Helion, Gliwice, 2003.
● Schmuller J.: UML dla każdego. Helion, Gliwice, 2003.
● Szejko S. (red.): Metody wytwarzania oprogramowania, Mikom,
Warszawa, 2002.
● Wrycza S. i inni: UML 2.1. Ćwiczenia. Helion, Gliwice, 2007.
● Yourdon E.: Współczesna analiza strukturalna. WNT Warszawa,
1996.
● Yourdon E., Argila C.: Analiza obiektowa i projektowanie. WNT
Warszawa, 2000..
K. Bartecki, Inżynieria oprogramowania, I/39