Inżynieria oprogramowania - k.bartecki.po.opole.pl fileInżynieria oprogramowania to wiedza...

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),


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


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


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.



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 !


"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



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ś!


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”



„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ć”


Katastrofy oprogramowania


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.


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.


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.


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".


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.


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.


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.


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 (!)



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.


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”.


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ą.


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).


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.


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.


Narzędzia CASE

Eliminacja błędów w oprogramowaniu

możliwa jest (w pewnym zakresie) dzięki

wykorzystaniu odpowiednich narzędzi CASE.


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.


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.


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.


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.


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.


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.



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.



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..


Inżynieria oprogramowania - k.bartecki.po.opole.pl fileInżynieria oprogramowania to wiedza...

Documents

Transcript of Inżynieria oprogramowania - k.bartecki.po.opole.pl fileInżynieria oprogramowania to wiedza...