Inzynieria oprogramowania
wykład I
prowadzący: dr in\
. Krzysztof Bartecki
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.
In\
ynieria oprogramowania  próba definicji
stanowi zbiór umiejętności, pojęć i procedur, mających pomóc ludziom
dobrze wykonywać pracę przy tworzeniu oprogramowania.
K. Bartecki, In\
ynieria oprogramowania, I/2
In\
ynieria oprogramowania  inna definicja
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, a więc powinno ono
być:
zgodne z wymaganiami i oczekiwaniami u\
ytkownika,
niezawodne,
efektywne,
łatwe w konserwacji,
ergonomiczne.
K. Bartecki, In\
ynieria oprogramowania, I/3
Dzięki in\
ynierii oprogramowania mo\
liwe stało się zaplanowanie oraz
implementacja oprogramowania zło\
onego z milionów linii kodu,
przeznaczonego dla nowego Airbusa A380
K. Bartecki, In\
ynieria oprogramowania, I/4
Historia rozwoju oprogramowania
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ądz
te\
ze względu na przekroczenie
zało\
onego czasu lub bud\
etu.
K. Bartecki, In\
ynieria oprogramowania, I/5
Historia rozwoju in\
ynierii oprogramowania
zakres In\
ynieria
lata błędy
oprogramowania
oprogramowania
drobne błędy
programy pisane przez
indywidualna -
bez większych
programistów dla siebie,
1950-1960
programisty
konsekwencji
komputery w nauce
du\
e programy dość du\
a cena za początki in\
ynierii
i pierwsze narzędzia brak przemyśleń w oprogramowania 
1960-1970
przetwarzania informacji tworzeniu oprogram.  rzemiosło
olbrzymie systemy
kryzys
rozwój in\
ynierii
informatyczne 
1970-1990
oprogramowania
oprogramowania
komputery  dla mas
kryzys
rozkwit in\
ynierii
wszechobecne oprogramowania 
od 1990
oprogramowania
próby eliminacji
K. Bartecki, In\
ynieria oprogramowania, I/6
Kryzys oprogramowania
 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/7
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/8
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
K. Bartecki, In\
ynieria oprogramowania, I/9
Katastrofy oprogramowania
1962  Zaraz po starcie rakieta
Mariner 1 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/10
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/11
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/12
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/13
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/14
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/15
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/16
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/17
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.
K. Bartecki, In\
ynieria oprogramowania, I/18
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/19
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/20
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/21
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/22
2005  Odrzutowiec Airbus A380 kosztuje około 5 miliardów euro więcej
i zostaje póz
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/23
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/24
Wniosek: błędy w oprogramowaniu to norma!
Nawet w dobrze przetestowanych i często usprawnianych programach
znajdują się błędy w kodzie. Lista najczęściej pojawiających się
w oprogramowaniu błędów (na podstawie badań firmy Coverity):
Częstotliwość
Typ błędu
występowania
Pusty wskaz
nik wskazujący na u\
ywany obszar pamięci 27,95 %
Próba u\
ycia niezwolnionej pamięci 25,73 %
Niedostępny kod programu 9,76 %
Próba u\
ycia w kodzie nieprzetestowanych zmiennych 8,30 %
Przepełnienie adresowanego statycznie obszaru pamięci 6,14 %
Operacje na zwolnionym obszarze pamięci 6,46 %
Brak przypisania wartości zmiennym 5,50 %
Wyliczone wartości zerowe u\
ywane bez sprawdzenia 5,85 %
Wyliczone wartości ujemne u\
ywane bez sprawdzenia 3,72 %
Wskaz
nik wskazujący na niedostępny obszar pamięci 0,62 %
Przepełnienie dynamicznie adresowanego obszaru pamięci 0,31 %
K. Bartecki, In\
ynieria oprogramowania, I/25
Zakres in\
ynierii oprogramowania
In\
ynieria oprogramowania obejmuje 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,
metody redukcji kosztów konserwacji oprogramowania.
K. Bartecki, In\
ynieria oprogramowania, I/26
Idea przyświecająca wytwarzaniu oprogramowania:
Myśląc o czymś bardzo skomplikowanym, nie próbuj
robić wszystkiego jednocześnie.
Podziel to na mniej zło\
one części i skoncentruj się
kolejno na ka\
dej z nich.
Z tego względu proces wytwarzania oprogramowania dzieli się na
pewne fazy.
K. Bartecki, In\
ynieria oprogramowania, I/27
Ogólne fazy procesu produkcji
oprogramowania
specyfikacja  na tym etapie następuje określenie i ustalenie wymagań,
które musi spełniać oprogramowanie,
projektowanie  ustalenie ogólnej architektury systemu, wymagań dla
poszczególnych jego składowych,
integracja  zintegrowanie poszczególnych składowych w jeden system,
testowanie całego systemu,
ewolucja  uruchomienie systemu, usuwanie wykrytych podczas jego
u\
ywania błędów, rozszerzanie systemu.
K. Bartecki, In\
ynieria oprogramowania, I/28
Modele cyklu \
ycia oprogramowania
model kaskadowy,
model przyrostowy (iteracyjny),
model prototypowy,
programowanie odkrywcze,
model spiralny,
model formalnych transformacji.
K. Bartecki, In\
ynieria oprogramowania, I/29
Model kaskadowy
W modelu kaskadowym (ang. waterfall model), nazywanym tak\
e
modelem liniowym, wszystkie podstawowe czynności przy tworzeniu
oprogramowania wykonywane są jako odrębne fazy projektowe, jedna po
drugiej.
Wymagania
Projektowanie
Implementacja
Testowanie
Konserwacja
K. Bartecki, In\
ynieria oprogramowania, I/30
Model kaskadowy  fazy
Faza określenia wymagań (ang. requirements)  określane są cele oraz
szczegółowe wymagania wobec tworzonego systemu,
Faza projektowania (ang. design)  powstaje szczegółowy projekt
systemu, spełniającego ustalone wcześniej wymagania,
Faza implementacji (ang. implementation)  projekt implementowany
(kodowany) jest w określonym środowisku programistycznym oraz
wykonywane są testy jego modułów,
Faza testowania (ang. verification)  następuje integracja oraz testowanie
całości oprogramowania,
Faza konserwacji (ang. maintenance)  oprogramowanie jest
wykorzystywane przez u\
ytkowników, a producent dokonuje jego
konserwacji (usuwanie błędów, rozszerzanie funkcji, wsparcie techniczne).
K. Bartecki, In\
ynieria oprogramowania, I/31
Dodatkowe fazy modelu kaskadowego
Wymagania Projektowanie Implementacja
Testowanie Konserwacja
Instalacja
Analiza
Strategiczna
Dokumentacja
Faza strategiczna (ang. strategy)  strategiczne decyzje dotyczące
kolejnych etapów prac,
Faza analizy (ang. analysis)  budowa logicznego modelu systemu,
Faza dokumentacji (ang. documentation)  wytwarzanie dokumentacji
u\
ytkownika,
Faza instalacji (ang. installation)  instalacja systemu i przekazanie
go u\
ytkownikowi.
K. Bartecki, In\
ynieria oprogramowania, I/32
Model kaskadowy z iteracjami
Jeśli któraś z faz da niezadowalający efekt, cofamy się, wykonując kolejne
iteracje, a\
do momentu, kiedy na końcu  schodków otrzymamy
satysfakcjonujący produkt.
Wymagania
Projektowanie
Implementacja
Testowanie
Konserwacja
K. Bartecki, In\
ynieria oprogramowania, I/33
Zalety modelu kaskadowego:
przejrzystość,
łatwość zarządzania przedsięwzięciem,
stanowi podstawę dla wielu innych modeli \
ycia oprogramowania.
Wady modelu kaskadowego:
narzucenie twórcom oprogramowania ścisłej kolejności wykonywania
prac  nie mo\
na przejść do następnej fazy przed zakończeniem
poprzedniej,
wysoki koszt błędów popełnionych we wstępnych fazach  iteracje są
bardzo kosztowne, gdy\
powtarzamy wiele czynności,
długa przerwa w kontaktach z klientem  projektowanie oraz
implementacja wykonywane są wyłącznie przez firmę programistyczną.
K. Bartecki, In\
ynieria oprogramowania, I/34
Model przyrostowy (iteracyjny)
W modelu przyrostowym (ang. incremental model), po określeniu
wymagań oraz zbudowaniu ogólnego projektu systemu, wybierany,
implementowany oraz dostarczany klientowi jest kolejny podzbiór funkcji
systemu.
wymagania
proces realizowany
ogólny projekt
iteracyjnie
wybór podzbioru
funkcji
projekt, imple-
mentacja, testy
dostarczenie
klientowi
K. Bartecki, In\
ynieria oprogramowania, I/35
Model przyrostowy  fazy
określenie całości wymagań (na ile uda się je sprecyzować), oraz
wykonanie wstępnego, ogólnego projektu całości systemu,
wybór pewnego podzbioru funkcji systemu,
szczegółowy projekt (zgodnie z modelem kaskadowym) oraz
implementacja części systemu realizującej wybrane funkcje,
testowanie zrealizowanego fragmentu i dostarczenie go klientowi,
powtarzanie kolejnych etapów (od wyboru nowego podzbioru funkcji), a\

do zakończenia implementacji całego systemu.
K. Bartecki, In\
ynieria oprogramowania, I/36
Zalety modelu przyrostowego:
częstsze ni\
w modelu kaskadowym kontakty z klientem,
brak konieczności definiowania z góry całości wymagań,
mo\
liwość wcześniejszego wykorzystania przez klienta fragmentów
systemu,
mo\
liwość elastycznego reagowania na opóz
nienia realizacji
fragmentu  przyspieszenie prac nad innymi częściami.
Wady modelu przyrostowego:
dodatkowy koszt związany z niezale\
ną realizacją fragmentów
systemu,
trudności z wycinaniem podzbioru funkcji w pełni niezale\
nych,
konieczność implementacji szkieletów (interfejs).
K. Bartecki, In\
ynieria oprogramowania, I/37
Model prototypowy
polega na stworzeniu podczas projektowania
prototypu systemu w celu przedyskutowania oraz
akceptacji ze strony klienta.
Metody budowy prototypu:
 rozpisanie interfejsów u\
ytkownika na kartce papieru,
realizacja wyłącznie interfejsu u\
ytkownika, np. z wykorzystaniem
narzędzi RAD (ang. Rapid Application Development),
niepełna realizacja  np. implementacja jedynie kilku modułów systemu,
implementacja metod działających jedynie w większości przypadków lub
dla niektórych danych, w celu pokazanie jedynie idei,
niskiej jakości system wykonany za pomocą modelu odkrywczego,
który stosunkowo szybko się wykonuje.
K. Bartecki, In\
ynieria oprogramowania, I/38
Zalety modelu prototypowego:
pozwala klientowi szybko zobaczyć jak
 mniej więcej będzie wyglądał system,
zwiększa zrozumienie twórców systemu co do potrzeb klienta,
w zale\
ności od rodzaju prototypu, mo\
e pozwalać rozpocząć
szkolenie obsługi systemu po stronie klienta,
prototyp jest łatwy do zmiany.
Wady modelu prototypowego:
wysoki koszt budowy systemu  po weryfikacji prototyp jest najczęściej
porzucany lub tylko częściowo wykorzystywany do budowy
właściwego systemu,
mo\
liwość nieporozumień z klientem  klient widzi  prawie gotowy
produkt, który w rzeczywistości jest dopiero w początkowej fazie
rozwoju.
K. Bartecki, In\
ynieria oprogramowania, I/39
Programowanie odkrywcze
Programowanie odkrywcze (ang. exploratory programming) to model,
w którym budowa systemu rozpoczyna się natychmiast po określeniu
ogólnych wymagań.
Zbudowany system jest weryfikowany przez klienta  je\
eli zostanie
uznany za nieodpowiedni, budowana (modyfikowana) jest kolejna jego
wersja  tak długo, a\
jedna z kolejnych jego wersji zadowoli klienta.
Określenie
Budowa Testowanie
ogólnych
systemu systemu
wymagań
System
Dostarczenie
działa
systemu
poprawnie?
K. Bartecki, In\
ynieria oprogramowania, I/40
Zalety programowania odkrywczego:
mo\
liwość stosowania przy bardzo trudnych
sytuacjach z określeniem wymagań klienta,
dobrze opisuje amatorski sposób tworzenia oprogramowania,
w profesjonalnych projektach dobrze nadaje się do budowy prototypu,
Wady programowania odkrywczego:
brak mo\
liwości opracowania i zachowania sensownej struktury
systemu,
testowanie odbywa się jedynie przy obecności klienta ze względu
na pełnych brak wymagań.
K. Bartecki, In\
ynieria oprogramowania, I/41
Model spiralny
W modelu spiralnym (ang. spiral model) proces tworzenia
oprogramowania ma postać spirali, której ka\
da pętla reprezentuje jedną
iterację procesu. Najbardziej wewnętrzna pętla przedstawia początkowe
etapy projektowania, np. studium wykonalności, kolejna definicji wymagań
systemowych, itd.
K. Bartecki, In\
ynieria oprogramowania, I/42
Model spiralny  fazy
Model spiralny składa się z czterech głównych faz, wykonywanych cyklicznie:
planowanie  definiowanie konkretnych celów, wymaganych w danej
fazie przedsięwzięcia.
analiza ryzyka  identyfikacja ograniczeń i zagro\
eń, Ustalanie planów
realizacji,
tworzenie i zatwierdzanie  tworzenie oprogramowania w oparciu
o najbardziej odpowiedni model, wybrany na podstawie oceny zagro\
eń,
ocena i planowanie  recenzja postępu prac i planowanie kolejnej fazy
przedsięwzięcia, bądz
zakończenie projektu.
K. Bartecki, In\
ynieria oprogramowania, I/43
Zalety modelu spiralnego:
mo\
na wykorzystać gotowe projekty,
faza oceny przeprowadzana w ka\
dym cyklu pozwala uniknąć błędów
lub odpowiednio wcześnie je wykryć,
cały czas istnieje mo\
liwość rozwijania projektu.
Wady modelu spiralnego:
metodologia nie do końca dopracowana  ka\
dy projekt jest inny
i powstaje w innych warunkach,
tworzenie w oparciu o ten model wymaga doświadczenia
w prowadzeniu tego typu projektów oraz wiedzy ekonomicznej
w zarządzaniu,
przeznaczony tylko dla du\
ych przedsięwzięć programistycznych.
K. Bartecki, In\
ynieria oprogramowania, I/44
Model formalnych transformacji
W metodzie formalnych transformacji (ang. formal transformations)
zakłada się, \
e wymagania systemowe zapisywane są w pewnym
formalnym języku.
Następnie podlegają one automatycznym (tzn. bez udziału ludzi)
transformacjom do kolejnych form coraz bli\
szych kodowi.
Formalna
Postać
Postać
. . .
specyfikacja
Kod
pośrednia
pośrednia
wymagań
K. Bartecki, In\
ynieria oprogramowania, I/45
Zalety modelu formalnych transformacji:
pełna automatyzacja procesu wytwarzania
oprogramowania,
wysoka niezawodność, jeśli nie popełniono błędów na etapie
określania wymagań.
Wady modelu formalnych transformacji:
trudność formalnej specyfikacji wymagań  polega ona tu właściwie na
napisaniu  programu rozwiązującego pewien problem, który podlegał
będzie stopniowej  kompilacji do poziomu kodu,
mała efektywność tak uzyskanego kodu,
brak dobrze rozwiniętych języków formalnej specyfikacji wymagań,
model stanowi właściwie jedynie propozycję teoretyczną, związaną
z tzw. nurtem formalnym in\
ynierii oprogramowania.
K. Bartecki, In\
ynieria oprogramowania, I/46