Inżynieria oprogramowania, wykład 1, slajd 1
Pojęcia podstawowe inżynierii
oprogramowania
dr inż. Grzegorz Bliźniuk
Inżynieria oprogramowania
wykład 1
Inżynieria oprogramowania, wykład 1, slajd 2
W czasie przygotowywania prezentacji do wykładów,
oprócz materiałów własnych wykładowcy i literatury
przedmiotu, wykorzystano materiały przygotowane przez
następujących Autorów (w kolejności alfabetycznej):
J.Górskiego, K.Kowalczyka,
D.Pierzchałę, K.Subietę, T.Tarnawskiego.
Podziękowania
Inżynieria oprogramowania, wykład 1, slajd 3
Literatura podstawowa przedmiotu
1. Paul Beynon-Davies, „Inżynieria systemów
informacyjnych”, WNT, Warszawa 1999;
2. Kazimierz Subieta, „Wstęp do inżynierii
oprogramowania”, wyd. PJWSTK, Warszawa 2003;
3.
Ian Sommerville, „Inżynieria oprogramowania”, WNT,
2003
4. Grzegorz Bliźniuk, „Badanie jakości programów
współbieżnych”, wyd. BelStudio, Warszawa 2004;
5. Janusz Górski (redakcja), „Inżynieria oprogramowania w
projekcie informatycznym”, w. II, wyd. Mikom, Warszawa
2000;
6. Grady Booch, James Rumbaugh, Ivar Jacobson, „UML.
Przewodnik użytkownika”, WNT, Warszawa, 2002;
7. Plus zasoby Internetu (tylko zdroworozsądkowo!)
Inżynieria oprogramowania, wykład 1, slajd 4
Literatura podstawowa przedmiotu
Inżynieria oprogramowania, wykład 1, slajd 5
Plan wykładu 1
1. Ewolucja języków i technik
programowania
2. Geneza i dziedzina inżynierii
oprogramowania
3. Modele procesu tworzenia
oprogramowania
4. Czynności procesu tworzenia
oprogramowania
Inżynieria oprogramowania, wykład 1, slajd 6
Ewolucja języków
i technik programowania
Inżynieria oprogramowania, wykład 1, slajd 7
Trochę historii maszyn … cyfrowych
1812
- Charles P. Babbage opracował i zbudował mechaniczną
"maszynę różnicową", wykonującą skomplikowane działania
metodą powtarzania kombinacji elementarnych operacji;
1840
- Augusta Ada, córka lorda Byrona, opublikowała pracę
na temat dorobku Babbage'a. W swoich notatkach zawarła
przemyślenia na temat przewagi systemu dwójkowego nad
dziesiętnym w konstrukcji maszyn matematycznych oraz pętlą
programową - została pierwszą w dziejach programistką;
1850
- George Boole opracował zasady algebry Boole'a;
1946
- powstał ENIAC (Electronic Numerical Integrator and
Computer), skonstruowany przez Johna W. Mauchly'ego i J.
Presper Eckerta z amerykańskiego Ballistic Research
Laboratory;
Inżynieria oprogramowania, wykład 1, slajd 8
Trochę historii …c.d.
1964
– w WAT zbudowano prototyp komputera analogowego
ELWAT produkowanego przez zakład Elwro;
1967
– opracowano w Norweskim Centrum Obliczeniowym w
Oslo język Simula, uważany za przodka obiektowości;
1972
- w Bell Laboratories opracowano język C;
1985
- Microsoft wypuścił na rynek Windows 1.0.
1991
- Linus Torvalds z Unwersytetu Helsińskiego opracował
odchudzoną wersję Unixa – Linux;
1996
- Microsoft zaprezentował Windows 95;
1996
- … era sieci globalnych, urządzeń programowalnych,
komputerów przenośnych;
… proponuję rozwinąć samodzielnie
Inżynieria oprogramowania, wykład 1, slajd 9
Język programowania
Język programowania jest środkiem umożliwiającym
zapis algorytmów w postaci zrozumiałej dla człowieka, a
równocześnie przetwarzanej do postaci zrozumiałej dla
komputera (maszyny algorytmicznej)
Kod źródłowy programu
(w języku programowania)
Kod wynikowy programu
(w języku maszynowym)
Przetworzenie
programu
źródłowego
w kod
maszynowy
Inżynieria oprogramowania, wykład 1, slajd 10
Semiotyka języka programowania
Semiotyka zajmuje się badaniem symboli, znaków. W
jej skład wchodzą:
– syntaktyka, zajmująca się określaniem przynależności danego
słowa do zestawu słownika określonego języka programowania
– semantyka, zajmująca się określeniem znaczenia programu,
zapisanego w określonym języku programowania
Zapis algorytmu w języku programowania jest
traktowany jako zapis formalny. Program
komputerowy jest uznawany za jeden z rodzajów
modeli matematycznych. Jest to algorytmiczny model
zadania czy też rzeczywistości, którą modelujemy.
Inżynieria oprogramowania, wykład 1, slajd 11
Syntaktyka języka programowania
Syntaktyka jest częścią ogólnej teorii znaków (semiotyki)
i zajmuje się strukturą i formą wyrażeń, a także
dopuszczalnymi zmianami ich formy, zwanymi
„przekształceniami”.
Wyróżnia się dwa rodzaje reguł składniowych:
– reguły formowania, określające zbiór wyrażeń poprawnie
zbudowanych na określonym alfabecie języka
– reguły przekształcania, określające zbiór możliwych
przekształceń na bazie słów z zadanego zestawu słownika
W dziedzinie algorytmiki, jak również logiki
matematycznej mają zastosowanie wyłącznie reguły
inferencyjne, tzn. takie przekształcenia, które są
prawdziwe w sensie logiki matematycznej
Inżynieria oprogramowania, wykład 1, slajd 12
Syntaktyka języka programowania
Najczęściej przyjmuje się, że mamy do czynienia z
dwoma podzbiorami dziedziny nazywanej syntaktyką:
– syntaktyka formalna, która jest rozumiana jako ogólne
badania formalne, dotyczące języków logiki i matematyki, jak
również języków naturalnych,
– syntaktyka logiczna, która zajmuje się badaniem języków
logiki i matematyki (np. rachunek predykatów, rachunek
zdań)
Językami programowania, badaniem ich
algorytmiczności zajmuje się syntaktyka języków
programowania, która jest jednym z rodzajów
syntaktyk formalnych
Inżynieria oprogramowania, wykład 1, slajd 13
Semantyka języka programowania
Semantyka zajmuje się interpretacją formuł zapisanych
zgodnie z określonymi regułami syntaktycznymi języka
Tarski (1936r.) zaproponował używanie pojęcia semantyka
naukowa dla określenia semantyki zajmującej się formalnym
badaniem prawdziwości formuł w zakresie znaczeniowym
definiowanego języka.
Od lat 70-tych 20 wieku rozwija się tzw, semantyka
wartości logicznych (SWL), inaczej nazywana semantyką
prawdziwo-ściową. Bazuje ona na pojęciu prawdy logicznej,
na wyrażeniach zwanych tautologiami.
Podstawą wnioskowania w SWL o prawdziwości reguły
logicznej jest dowiedzenie poprawności zdania logicznego
wyprowadzanego na podstawie kombinacji innych,
prawdziwych zdań logicznych
Inżynieria oprogramowania, wykład 1, slajd 14
Rodzaje języków oprogramowania
Category
Ratings March
2008
Delta March
2007
Object-Oriented Languages 54.9%
+3.0%
Procedural Languages
42.8%
-1.4%
Functional Languages
1.6%
-0.6%
Logical Languages
0.7%
-1.0%
Źródło: www.tiobe.com
Inżynieria oprogramowania, wykład 1, slajd 15
Przykłady języków programowania
Poruszamy się w kręgu języków programowania z rodziny
Algol’60. Przedstawicielami tej rodziny są między innymi
takie języki programowania, jak:
– Simula,
– Pascal (Niklaus Wirth),
– Modula2 (Niklaus Wirth),
– MODSIM II – symulacyjny język programowania (CACI),
– C (Dennis Ritchie),
– C++ (obiektowe rozszerzenie języka C)
– C# - obiektowy dla środowiska .NET
– Visual Basic (Microsoft)
– Ada (na zamówienie Pentagonu)
– Java (pochodna języka C++)
Inżynieria oprogramowania, wykład 1, slajd 16
Ranking popularności języków
programowania
na marzec 2008
Position
Mar 2008
Position
Mar 2007
Programming Language
Ratings
Mar 2008
Delta
Mar 2007
1
1
20.651%
+2.61%
2
2
15.593%
-0.04%
3
5
10.795%
+2.65%
4
4
10.138%
+0.68%
5
3
9.776%
-1.33%
6
6
5.781%
-0.64%
7
7
4.593%
+0.70%
8
9
4.143%
+0.78%
9
12
2.697%
+0.94%
10
10
2.661%
-0.11%
11
8
2.462%
-1.02%
Źródło: www.tiobe.com
Inżynieria oprogramowania, wykład 1, slajd 17
Zmiany popularności języków
programowania
w ostatnich kilku latach
Źródło: www.tiobe.com
Inżynieria oprogramowania, wykład 1, slajd 18
Geneza i dziedzina
inżynierii oprogramowania
Inżynieria oprogramowania, wykład 1, slajd 19
Kryzys oprogramowania
Od początku lat 60-tych trwa walka z syndromem LOOP;
1968, 1969 - konferencje sponsorowane przez NATO w Garmisch i Rzymie;
L
O
O
P
ate (późno)
oor quality (kiepska
jakość)
ver budget (przekroczony
budżet)
vertime (nadgodziny)
Loop
Inżynieria oprogramowania, wykład 1, slajd 20
Kryzys oprogramowania
Lata Oprogramowanie
Kryzys
Stan ‘Inż.
Opr.’
1950
–
1960
Tworzone dla siebie
Błędy własne
Brak
1960
–
1970
Duże systemy
Początek
kryzysu,
kosztowne
błędy
Powstaje,
1970
–
1990
Powszechnie
dostępne komputery,
duże i masowo
dystrybuowane
oprogr.
Błędy
powszechnie
występujące
Rozkwit
inżynierii
1990
– …
Uzależnienie
gospodarki i wielu
dziedzin życia od
komputerów
Kryzys trwa w
dalszym ciągu
Rozwój trwa –
nowe teorie i
praktyki
Inżynieria oprogramowania, wykład 1, slajd 21
Kryzys oprogramowania
Zasadnicze problemy wytwórców oprogramowania:
–wzrost mocy sprzętu zwiększa zapotrzebowanie na nowe,
bardziej złożone oprogramowanie;
–długi i kosztowny cykl wytwarzania oprogramowania;
–frustracje projektantów oprogramowania i programistów
wynikające ze zbyt szybkiego postępu w zakresie języków,
narzędzi i metod;
–uzależnienie organizacji od systemów komputerowych i
przyjętych technologii przetwarzania informacji, które nie są
stabilne w długim horyzoncie czasowym;
–brak kontaktów pomiędzy użytkownikiem i firmą;
–problemy współdziałania niezależnie zbudowanego
oprogramowania, szczególnie istotne przy dzisiejszych
tendencjach integracyjnych;
–niska kultura ponownego użycia wytworzonych komponentów
projektów i oprogramowania;
–zbyt późne wykrywanie błędów i słabych punktów;
–brak koordynacji w pracy zespołów projektowych;
–ogromne koszty utrzymania oprogramowania;
Inżynieria oprogramowania, wykład 1, slajd 22
Kryzys oprogramowania
Podstawowym powodem kryzysu
oprogramowania jest złożoność produktów
informatyki i procesów ich wytwarzania
Dane empiryczne:
–27% projektów powstaje w założonym czasie,
budżecie i funkcjonalności
–
33% projektów przekracza czas, budżet i ma
mniejszą funkcjonalność
–
40% projektów jest przerywanych
–
53% projektów przekracza koszty o 51%
–
68% projektów przekracza czas o 51%
Inżynieria oprogramowania, wykład 1, slajd 23
Kryzys oprogramowania
Inżynieria oprogramowania, wykład 1, slajd 24
Kryzys oprogramowania
Źródła złożoności projektu oprogramowania:
–
Dziedzina problemowa - obejmuje ogromną liczbę
wzajemnie uzależnionych aspektów i problemów;
–
Środki i technologie informatyczne - sprzęt,
oprogramowanie, sieć, języki, narzędzia, udogodnienia;
–
Zespół projektantów - podlega ograniczeniom pamięci,
percepcji, wyrażania informacji i komunikacji;
–
Potencjalni użytkownicy - czynniki psychologiczne,
ergonomia, ograniczenia pamięci i percepcji, skłonność
do błędów i nadużyć, tajność, prywatność;
Inżynieria oprogramowania, wykład 1, slajd 25
Walka z kryzysem oprogramowania
Stosowanie technik i narzędzi ułatwiających pracę
nad złożonymi systemami;
Korzystanie z metod wspomagających analizę
nieznanych
problemów
oraz
ułatwiających
wykorzystanie wcześniejszych doświadczeń;
Usystematyzowanie
procesu
wytwarzania
oprogramowania, tak aby ułatwić jego planowanie i
monitorowanie;
Wytworzenie wśród producentów i nabywców
przekonania, że budowa dużego systemu wysokiej
jakości jest zadaniem wymagającym profesjonalnego
podejścia.
Podstawowym powodem kryzysu oprogramowania
jest
złożoność produktów informatyki i procesów ich
wytwarzania.
Inżynieria oprogramowania, wykład 1, slajd 26
Co to jest inżynieria oprogramowania?
Jest to dziedzina inżynierii, która obejmuje wszystkie
aspekty tworzenia oprogramowania od fazy początkowej do
jego pielęgnacji;
Inżynieria oprogramowania jest wiedzą empiryczną,
syntezą doświadczenia wielu ośrodków zajmujących się
budową oprogramowania;
Informatyka obejmuje teorie i podstawowe zasady działania
komputerów a inżynieria oprogramowania obejmuje
praktyczne problemy konstruowania oprogramowania;
Zajmuje się efektywnymi teoriami, metodami i narzędziami
związanymi z procesem wytwarzania oprogramowania;
Zastosowanie systematycznego, zdyscyplinowanego,
ilościowego podejścia do wykonywania,
wykorzystywania
i konserwowania oprogramowania [IEEE 93];
Inżynieria oprogramowania, wykład 1, slajd 27
Co to jest inżynieria oprogramowania?
Kierunki rozwoju Inżynierii Oprogramowania:
–formalny − stosowanie metod formalnych (języków
specyfikacji, transformacji, dowodów poprawności) w celu
dowodzenia, że program spełnia specyfikację:
»indukcja matematyczna we wszystkich możliwych odmianach;
»formalna transformacja specyfikacji w spełniający ją program – np.
metoda VDM Johns’a;
»metody uproszczone - np. logika Hoare'a oparta na niezmiennikach
pętli, logika Pnuelli’ego,
–empiryczny − notacje nie w pełni sformalizowane,
graficzne, w których dużą rolę odgrywa wiedza i
doświadczenie ludzkie;
To tzw. dobre praktyki – słabo zintegrowana lista
zdroworozsądkowych rad na różne sytuacje;
Inżynieria oprogramowania, wykład 1, slajd 28
Przedmiot inżynierii oprogramowania
Inżynieria
oprogramowania
jest
wiedzą
techniczną
dotycząca wszystkich faz cyklu życia oprogramowania.
Traktuje oprogramowanie jako produkt, który ma spełniać
potrzeby techniczne, ekonomiczne lub społeczne.
Dobre oprogramowanie powinno być:
zgodne z wymaganiami użytkownika,
niezawodne,
efektywne,
łatwe w konserwacji,
interoperacyjne (jeżeli nie jest autonomiczne)
ergonomiczne.
Produkcja oprogramowania jest procesem składającym się z
wielu faz. Kodowanie (pisanie programów) jest tylko jedną z
nich, niekoniecznie najważniejszą.
Inżynieria oprogramowania jest wiedzą empiryczną,
syntezą doświadczenia tysięcy ośrodków zajmujących się
budową oprogramowania.
Inżynieria oprogramowania, wykład 1, slajd 29
Zagadnienia inżynierii
oprogramowania
Sposoby
prowadzenia
przedsięwzięć
informatycznych.
Techniki
planowania,
szacowania
kosztów,
harmonogramowania i monitorowania przedsięwzięć
informatycznych.
Metody analizy i projektowania systemów.
Techniki
zwiększania
niezawodności
oprogramowania.
Sposoby
testowania
systemów
i
szacowania
niezawodności.
Sposoby przygotowania dokumentacji technicznej i
użytkowej.
Procedury kontroli jakości.
Metody redukcji kosztów konserwacji (usuwania
błędów, modyfikacji i rozszerzeń)
Techniki pracy zespołowej i czynniki psychologiczne
wpływające na efektywność pracy.
Inżynieria oprogramowania, wykład 1, slajd 30
Struktura rynku informatycznego w
USA
Programiści i Użytkownicy Końcowi
(55 mln w Stanach Zjednoczonych)
Generatory Aplikacji i
Wspomaganie Wytwarzania
Oprogramowania
(0.6 mln)
Wytwarzanie Aplikacji
dla warstwy pośredniej
(0.7 mln)
Integratorzy Systemów
(0.7 mln)
Infrastruktura informatyczna
(0.75 mln)
Struktura rynku informatycznego USA w roku 2005
Inżynieria oprogramowania, wykład 1, slajd 31
Źródła złożoności projektu
oprogramowania
Zespół projektantów
podlegający
ograniczeniom pamięci,
percepcji, wyrażania
informacji i komunikacji.
Zespół projektantów
podlegający
ograniczeniom pamięci,
percepcji, wyrażania
informacji i komunikacji.
Dziedzina
problemowa,
obejmująca ogromną
liczbę wzajemnie
uzależnionych aspektów i
problemów.
Dziedzina
problemowa,
obejmująca ogromną
liczbę wzajemnie
uzależnionych aspektów i
problemów.
Środki i technologie
informatyczne:
sprzęt, oprogramowanie,
sieć,
języki, narzędzia,
udogodnienia.
Środki i technologie
informatyczne:
sprzęt, oprogramowanie,
sieć,
języki, narzędzia,
udogodnienia.
Oprogramowanie
:
decyzje strategiczne,
analiza,
projektowanie,
konstrukcja,
dokumentacja,
wdrożenie,
szkolenie,
eksploatacja,
pielęgnacja,
modyfikacja.
Potencjalni
użytkownicy:
czynniki psychologiczne,
ergonomia, ograniczenia
pamięci i percepcji,
skłonność do błędów i
nadużyć, tajność,
prywatność.
Potencjalni
użytkownicy:
czynniki psychologiczne,
ergonomia, ograniczenia
pamięci i percepcji,
skłonność do błędów i
nadużyć, tajność,
prywatność.
Inżynieria oprogramowania, wykład 1, slajd 32
Jak walczyć ze złożonością ?
Zasada dekompozycji:
rozdzielenie złożonego problemu na podproblemy, które można
rozpatrywać i rozwiązywać niezależnie od siebie i niezależnie
od całości.
Zasada abstrakcji:
eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów
rozważanego przedmiotu lub mniej istotnej informacji;
wyodrębnianie cech wspólnych i niezmiennych dla pewnego
zbioru bytów i wprowadzaniu pojęć lub symboli oznaczających
takie cechy.
Zasada ponownego użycia:
wykorzystanie wcześniej wytworzonych schematów, metod,
wzorców,
komponentów
projektu,
komponentów
oprogramowania, itd.
Zasada
sprzyjania
naturalnym
ludzkim
własnościom:
dopasowanie modeli pojęciowych i modeli realizacyjnych
systemów
do
wrodzonych
ludzkich
własności
psychologicznych, instynktów oraz mentalnych mechanizmów
percepcji i rozumienia świata.
Inżynieria oprogramowania, wykład 1, slajd 33
Proces wytwarzania oprogramowania
Jest to zbiór czynności i związanych z nimi wyników,
które prowadzą do powstania produktu programowego;
Zasadnicze czynności wspólne dla wszystkich procesów:
–Specyfikowanie oprogramowania
»Funkcjonalność oprogramowania i ograniczenia jego działania muszą
być zdefiniowane;
–Projektowanie i implementowanie oprogramowania
»Oprogramowanie, które spełnia specyfikację, musi być stworzone;
–Zatwierdzenie oprogramowania
»Wytworzone oprogramowanie musi spełniać oczekiwania klienta;
–Ewolucja oprogramowania
»Oprogramowanie musi ewoluować, aby spełniać zmieniające się
potrzeby użytkowników;
Inżynieria oprogramowania, wykład 1, slajd 34
Modelowanie pojęciowe
Projektant i programista muszą dokładnie wyobrazić
sobie problem oraz metodę jego rozwiązania.
Zasadnicze procesy tworzenia oprogramowania
zachodzą w ludzkim umyśle i nie są związane z
jakimkolwiek językiem programowania.
Pojęcia modelowania pojęciowego (conceptual
modeling) oraz modelu pojęciowego (conceptual
model) odnoszą się procesów myślowych i wyobrażeń
towarzyszących pracy nad oprogramowaniem.
Modelowanie pojęciowe jest wspomagane przez
środki wzmacniające ludzką pamięć i wyobraźnię.
Służą
one
do
przedstawienia
rzeczywistości
opisywanej przez dane, procesów zachodzących w
rzeczywistości, struktur danych oraz programów
składających się na konstrukcję systemu.
Inżynieria oprogramowania, wykład 1, slajd 35
Perspektywy w modelowaniu
pojęciowym
Percepcja
rzeczywistego
świata
Analityczny
model
rzeczywistości
Model
struktur danych
i procesów SI
... ... ...
... ... ...
... ... ...
... ... ...
... ... ...
... ... ...
Trwałą tendencją w rozwoju metod i narzędzi projektowania
oraz konstrukcji SI jest dążenie do minimalizacji luki
pomiędzy myśleniem o rzeczywistym problemie a myśleniem
o danych i procesach zachodzących na danych.
odwzorowanie
odwzorowanie
Inżynieria oprogramowania, wykład 1, slajd 36
Co to jest metodyka (metodologia)?
Metodyka jest to zestaw pojęć, notacji, modeli,
języków, technik i sposobów postępowania
służący do analizy dziedziny stanowiącej przedmiot
projektowanego systemu oraz do projektowania
pojęciowego, logicznego i/lub fizycznego.
Metodyka jest powiązana z notacją służącą do
dokumentowania wyników faz projektu (pośrednich,
końcowych), jako środek wspomagający ludzką
pamięć i wyobraźnię i jako środek komunikacji w
zespołach oraz pomiędzy projektantami i klientem.
Metodyka
ustala:
Metodyka
ustala:
• fazy projektu, role uczestników projektu,
• modele tworzone w każdej z faz,
• scenariusze postępowania w każdej z faz,
• reguły przechodzenia od fazy do
następnej fazy,
• notacje, których należy używać,
• dokumentację powstającą w każdej z faz.
methodology
Inżynieria oprogramowania, wykład 1, slajd 37
Modele procesu
wytwarzania oprogramowania
Inżynieria oprogramowania, wykład 1, slajd 38
Cykl życia oprogramowania
Faza strategiczna: określenie strategicznych celów, planowanie i
definicja projektu
Określenie wymagań: co system ma robić?
Analiza: dziedziny przedsiębiorczości, wymagań systemowych
Projektowanie: projektowanie pojęciowe, projektowanie
logiczne
Implementacja/konstrukcja: rozwijanie, testowanie,
dokumentacja
Testowanie: sprawdzanie, czy system działa tak, jak założono w
specyfikacji
Dokumentacja: wszystkie produkty muszą być dokumentowane
Instalacja: uruchomienie systemu w środowisku pracy
Przygotowanie użytkowników, akceptacja, szkolenie
Działanie, włączając wspomaganie tworzenia aplikacji
Utrzymanie, konserwacja, pielęgnacja
Wycofanie wersji z ekploatacji: tzw. utylizacja oprogramowania
software lifecycle
Inżynieria oprogramowania, wykład 1, slajd 39
Modele cyklu życia oprogramowania
Model kaskadowy
(wodospadowy)
Model spiralny, przyrostowy, ewolucyjny
Prototypowanie
Programowanie odkrywcze
Model „V”
Montaż z gotowych komponentów
Tego rodzaju modeli (oraz ich mutacji) jest bardzo dużo.
Określenie wymagań
ProjektowanieImplementacjaTestowanieKonserwacja
Faza strategiczna Analiza
Instalacja
Dokumentacja
Inżynieria oprogramowania, wykład 1, slajd 40
Model kaskadowy
(wodospadowy)
Określenie
wymagań
Określenie
wymagań
Projektowanie
Projektowanie
Implementacja
Implementacja
Testowanie
Testowanie
Konserwacja
Konserwacja
Cele i szczegółowe wymagania wobec systemu.
Szczegółowy projekt
systemu uwzględniający
wcześniejsze
wymagania.
Modyfikacje producenta -
usunięcie błędów, zmiany i
rozszerzenia.
Analiza
Analiza
waterfall model
Inżynieria oprogramowania, wykład 1, slajd 41
Ocena modelu kaskadowego
Narzucenie twórcom oprogramowania ścisłej kolejności wykonywania prac
Wysoki koszt błędów popełnionych we wczesnych fazach
Długa przerwa w kontaktach z klientem
Istnieją zróżnicowane poglądy co do przydatności
praktycznej modelu kaskadowego. Podkreślane są następujące
wady:
Z drugiej strony, jest on do pewnego stopnia niezbędny dla
planowania, harmonogramowania, monitorowania i rozliczeń
finansowych.
Określenie
wymagań
Określenie
wymagań
Analiza
Projektowanie
Analiza
Projektowanie
Implementacja
Implementacja
Testowanie
Testowanie
Konserwacja
Konserwacja
Zmodyfikowany model
kaskadowy z iteracjami
Inżynieria oprogramowania, wykład 1, slajd 42
Piramida propagacji błędów
Pielęgnacja
Implementacja
Projekt
Analiza
Wymag
ania
Rozmiar kosztu usunięcia błędów
E
ta
p
c
yk
lu
ż
yc
ia
op
ro
g
ra
m
ow
an
ia
Inżynieria oprogramowania, wykład 1, slajd 43
Realizacja kierowana dokumentami
Przyjęty przez armią amerykańską dla realizacji projektów w
języku Ada.
Jest to odmiana modelu kaskadowego.
Każda faza kończy się sporządzeniem szeregu dokumentów, w
których opisuje się
wyniki danej fazy.
Łatwe planowanie, harmonogramowanie oraz monitorowanie
przedsięwzięcia.
Dodatkowa zaleta: (teoretyczna) możliwość realizacji dalszych faz
przez inną firmę.
Wady
Duży nakład pracy na opracowanie dokumentów zgodnych
ze standardem (DOD STD 2167) - ponad 50% całkowitych
nakładów.
Przerwy w realizacji niezbędne dla weryfikacji
dokumentów przez klienta.
Inżynieria oprogramowania, wykład 1, slajd 44
Ponowne użycie - reuse
Tworzenie z użyciem wielokrotnym
(reuse):
•W przedsięwzięciach programistycznych
występuje wielokrotne użycie oprogramowania;
•Zakłada się zatem konieczność posiadania
zbioru komponentów programowych do
wielokrotnego użycia oraz elementów
integrujących;
Specyfikacja
wymagań
Zatwierdzen
ie
systemu
Tworzenie i
integracja
Projekt
systemu z
użyciem
wielokrotnym
Analiza
komponentów
Modyfikacja
wymagań
Wada: niezamierzone przez
klienta lecz wymuszone przez
wytwórcę dostosowanie
wymagań!
Inżynieria oprogramowania, wykład 1, slajd 45
Ponowne użycie - reuse
Kładzie nacisk na możliwość redukcji nakładów poprzez
wykorzystanie podobieństwa tworzonego oprogramowania do
wcześniej tworzonych systemów oraz wykorzystanie gotowych
komponentów dostępnych na rynku.
Jest również określany jako wykorzystanie
wielokrotne
zakup elementów ponownego użycia od dostawców
przygotowanie elementów poprzednich przedsięwzięć do
ponownego użycia
wysoka niezawodność
zmniejszenie ryzyka
efektywne wykorzystanie specjalistów
narzucenie standardów
dodatkowy koszt przygotowania elementów ponownego
użycia
ryzyko uzależnienia się od dostawcy elementów
niedostatki narzędzi wspomagających ten rodzaj pracy.
Metody
Zalety
Wady
Inżynieria oprogramowania, wykład 1, slajd 46
Model „V” cyklu życia oprogramowania
Specyfikacja
Projekt
systemu
Projekt podsystemu
Projekt modułu
Integracja i walidacja systemu
Formalne testowanie modułu
Integracja i walidacja
podsystemu
Testy akceptacyjne
systemu
Kodowanie, wstępne testowanie
modułu
Model V jest często stosowany w metodykach „Rational” bazujących na języku UML
Inżynieria oprogramowania, wykład 1, slajd 47
Model ewolucyjny
Wytwarzanie ewolucyjne - polega na:
–opracowaniu wstępnej implementacji,
–pokazaniu jej użytkownikowi z prośbą o
komentarze
–oraz udoskonalaniu jej w wielu wersjach aż do
powstania odpowiedniego systemu;
Inżynieria oprogramowania, wykład 1, slajd 48
Rodzaje modelu ewolucyjnego
•
Rodzaje wytwarzania ewolucyjnego:
•Tworzenie badawcze:
»Celem procesu jest praca z klientem, polegająca na badaniu
wymagań i dostarczeniu ostatecznego systemu;
»Tworzenie rozpoczyna się od tych części systemu, które są
dobrze rozpoznane;
»System ewoluuje przez dodawanie nowych cech, które proponuje
klient;
•Prototypowanie z porzuceniem:
»Celem procesu tworzenia ewolucyjnego jest zrozumienie
wymagań klienta i wypracowanie lepszej definicji wymagań
stawianych systemowi;
»Budowanie prototypu ma głównie na celu eksperymentowanie z
tymi wymaganiami użytkownika, które są niejasne;
Inżynieria oprogramowania, wykład 1, slajd 49
Wady modelu ewolucyjnego
•
Wady modelu ewolucyjnego:
•Proces nie jest widoczny;
•System ma złą strukturę;
•Konieczne mogą być specjalne narzędzia i techniki;
•
Stosowanie:
–W wypadku systemów małych (mniej niż 100 000
wierszy kodu) lub średnich (do 500 000 wierszy kodu)
z krótkim czasem życia podejście ewolucyjne jest
dobre;
–W wypadku dużych systemów o długim czasie życia
wady tworzenia ewolucyjnego ujawniają się jednak z
całą ostrością;
Inżynieria oprogramowania, wykład 1, slajd 50
Modele formalne
Tworzenie formalne systemów:
–Tworzenie formalne systemów jest podejściem,
które ma cechy modelu kaskadowego;
–Proces tworzenia jest oparty na
matematycznych przekształceniach specyfikacji
systemu w program wykonywalny;
Podejście stosukowo słabo przydatne w pracach praktycznych,
co jest szkodliwe dla kunsztu matematycznego, ale wymusza to rynek.
Inżynieria oprogramowania, wykład 1, slajd 51
Programowanie odkrywcze
Model odkrywczy ma znaczenie wyłącznie w zastosowaniach amatorskich
Określ ogólne
wymagania
Przetestuj system
Zbuduj system
Dostarcz system
zadawala
tak
nie
Inżynieria oprogramowania, wykład 1, slajd 52
Rozszerzenia modeli cyklu życia
oprogramowania
Rozszerzenia modeli ogólnych:
–Wszystkie omówione modele nie są pozbawione
wad, zatem stosowane są podejścia hybrydowe
lub indywidualnie dostosowane do wymagań i
celów;
–Hybrydowe modele:
»model spiralny,
»model przyrostowy,
»prototypowanie;
Inżynieria oprogramowania, wykład 1, slajd 53
Model spiralny (Boehm, 1988)
Istnieje wiele wariantów tego modelu.
Planowanie: Ustalenie
celów produkcji
kolejnej wersji
systemu
Analiza ryzyka
(ew. budowa prototypu)
Konstrukcja
(model kaskadowy)
Atestowanie (przez klienta).
Jeżeli ocena nie jest w pełni
pozytywna, rozpoczynany jest
kolejny cykl.
spiral model
Inżynieria oprogramowania, wykład 1, slajd 54
Model spiralny – inny wariant
Tworzenie spiralne
Określ cele,
inne strategie
i ograniczenia
Oceń inne strategie,
rozpoznaj i zmniejsz
zagrożenia
(ocena ryzyka technicznego)
RECENZJA
Plan wymagań
Plan cyklu życia
Plan tworzenia
Plan testowania
i integracji
Zaplanuj następną
fazę
Analiza zagrożeń
Analiza zagrożeń
Analiza zagrożeń
Analiza
zagrożeń
Prototyp 1
Prototyp 2
Prototyp 3
Działający
prototyp
Sposób
postępowania
Symulacje, modele, miary odniesienia
Zatwierdzenie
wymagań
Wymagania
S/W Projekto-
wanie
produktu
Weryfikacja i
zatwierdzenie
Działanie
Testy
akceptacji
Testy
integracji
Testy
jednostek
Kodowanie
Szczegółowe
projekto-
wanie
Utwórz, zweryfikuj
produkt następnego
poziomu
Inżynieria oprogramowania, wykład 1, slajd 55
Prototypowanie
Sposób na uniknięcie zbyt wysokich kosztów błędów
popełnionych w fazie określania wymagań. Zalecany w
przypadku, gdy określenie początkowych wymagań jest
stosunkowo łatwe.
Fazy
ogólne określenie wymagań
budowa prototypu
weryfikacja prototypu przez klienta
pełne określenie wymagań
realizacja pełnego systemu zgodnie z modelem kaskadowym
Cele
wykrycie nieporozumień pomiędzy klientem a twórcami systemu
wykrycie brakujących funkcji
wykrycie trudnych usług
wykrycie braków w specyfikacji wymagań
Zalety możliwość demonstracji pracującej wersji systemu
możliwość szkoleń zanim zbudowany zostanie pełny system
prototyping
Inżynieria oprogramowania, wykład 1, slajd 56
Metody prototypowania
Niepełna realizacja: objęcie tylko części funkcji
Języki wysokiego poziomu: Smalltalk, Lisp, Prolog,
4GL, ...
Wykorzystanie gotowych komponentów
Generatory interfejsu użytkownika: wykonywany jest
wyłącznie interfejs, wnętrze systemu jest “podróbką”.
Szybkie programowanie (quick-and-dirty): normalne
programowanie, ale bez zwracania uwagi na niektóre jego
elementy, np. zaniechanie testowania
Dość często następuje ewolucyjne przejście od prototypu do
końcowego systemu. Należy starać się nie dopuścić do
sytuacji, aby klient miał wrażenie, że prototyp jest prawie
ukończonym produktem. Po fazie prototypowania najlepiej
prototyp skierować do archiwum.
Inżynieria oprogramowania, wykład 1, slajd 57
Model iteracyjny (przyrostowy)
ocena
wymagania
planowanie
planowanie
wstępne
analiza i projektowanie
implementowanie
testowanie
dystrybucja
zarządzanie
środowiskiem
Inżynieria oprogramowania, wykład 1, slajd 58
Model iteracyjny
wczesne iteracje zajmują się największym ryzykiem;
w każdej powstaje wersja uruchomieniowa;
każda iteracja zawiera integrację i testowanie;
projekt realizuje się przyrostowo - każdy; „przyrost” jest
podzbiorem funkcjonalnym systemu;
model iteracyjny:
–ułatwia detekcję ryzyka zanim się dokona dużych inwestycji;
–zapobiega utknięciu całego systemu w martwym punkcie;
–umożliwia wczesną reakcję użytkownika;
–zapewnia ciągłe testowanie i integrację;
–zwraca szczególną uwagę na krótko-terminowość wykonania
projektu;
–umożliwia dystrybucję częściowych implementacji;
Inżynieria oprogramowania, wykład 1, slajd 59
Ryzyko projektowe
czas
ry
zy
k
o
Model kaskadowy
Model iteracyjny
Profil ryzyka
Redukcja ryzyka
Inżynieria oprogramowania, wykład 1, slajd 60
Cykl życia oprogramowania w normie
IEC 300-3-6
Analiza
wymagań
Specyfikacja
systemu
Projekt
wstępny
Projekt
szczegółowy
Kodowanie,
Testy
komponentów
Testy
integracyjne
Testy
systemu
Testy
akceptacyjne
Wdrożenie
oprogramow.
Utrzymywanie,
ulepszanie
oprogramowania
Dezaktua-
lizacja
oprogra-
mowania
Cykl życia
oprogramowania
Cykl życia oprogramowania (według IEC 300-3-6)
upływ czasu
Koncepcja,
Definicja
Projekt,
Technologia
Produkcja,
Instalacja
Działanie,
Konserwacja
Usunięcie
Cykl życia wyrobu
Inżynieria oprogramowania, wykład 1, slajd 61
Czynności procesu
wytwarzania oprogramowania
Inżynieria oprogramowania, wykład 1, slajd 62
Specyfikowanie oprogramowania
Specyfikowanie oprogramowania:
–Ma na celu określenie, jakich usług wymaga się
od systemu i jakim ograniczeniom podlega
tworzenie i działanie oprogramowania;
–Obecnie jest nazywane inżynierią wymagań;
–W procesie inżynierii wymagań możemy
wyróżnić cztery główne fazy:
»studium wykonalności,
»określenie i analiza wymagań,
»specyfikowanie wymagań,
»zatwierdzanie wymagań;
Inżynieria oprogramowania, wykład 1, slajd 63
Określenie i analiza
wymagań
Specyfikacja
wymagań
Modele
systemu
Wymagania
użytko-
wnika systemu
Zatwierdza
nie
wymagań
Raport o
wykonywalności
Studium
wykonalnoś
ci
Dokumentacja
wymagań
Specyfikowanie oprogramowania
Specyfikowanie oprogramowania:
Inżynieria oprogramowania, wykład 1, slajd 64
Projekt i implementacja
Projektowanie i implementowanie wymagań:
–Projekt oprogramowania to opis struktury
oprogramowania, które ma być zaimplementowane,
opis danych, które są częścią systemu, opis
interfejsów między komponentami systemu i
użytych algorytmów;
–Proces projektowania może obejmować
opracowanie wielu modeli systemu na różnych
poziomach abstrakcji;
–Faza implementowania w tworzeniu
oprogramowania to proces przekształcania
specyfikacji systemu w działający system;
Inżynieria oprogramowania, wykład 1, slajd 65
Projekt i implementacja
Projektowanie i implementowanie
wymagań:
–Charakterystyczne składowe procesu
projektowania:
Projektowanie
architektury
Specyfikowanie
abstrakcyjne
Projektowanie
interfejsów
Projektowanie
komponentów
Architektura
systemu
Specyfikacja
programowania
Specyfikacja
interfejsów
Specyfikacja
komponentów
Projektowanie
struktury
danych
Specyfikacja
struktury
danych
Specyfikacja
algorytmów
Projektowanie
algorytmów
Specyfikacja
wymagań
Produkty projektowania
Składowe projektowe
Inżynieria oprogramowania, wykład 1, slajd 66
Projekt i implementacja
Projektowanie i implementowanie wymagań:
–Metody projektowania:
»Stosowanie metod strukturalnych i obiektowych, które są zbiorami
notacji i porad dla projektantów oprogramowania;
»Ich użycie polega głównie na opracowaniu graficznych modeli
systemu oraz opisów tekstowych wg ustalonych szablonów;
»Metody strukturalne obejmują np.:
modele przepływu danych,
modele encja-związek;
»Niezwykle popularne ostatnio są metody obiektowe, w tym np.:
modele klas, dynamiki,
modele architektury;
–Niestety wciąż jeszcze projektowanie jest działaniem ad
hoc, gdzie wymagania zapisuje się w języku naturalnym;
Inżynieria oprogramowania, wykład 1, slajd 67
Weryfikacja i walidacja
Zatwierdzanie oprogramowania:
–
Weryfikacja i zatwierdzenie mają wykazać, że
system jest zgodny ze swoją specyfikacją i
spełnia oczekiwania klienta;
–
Obejmuje proces sprawdzania, m.in. kontrole i
recenzje w każdym kroku procesu tworzenia od
definicji wymagań użytkownika do pisania
programów;
–
Większość kosztów zatwierdzania powstaje po
zaimplementowaniu, gdy testuje się działający
system
Inżynieria oprogramowania, wykład 1, slajd 68
Rodzaje testowania oprogramowania
Zatwierdzanie oprogramowania:
–Testowanie komponentów (jednostek)
»Testuje się poszczególne komponenty, aby zapewnić, że działają poprawnie;
–Testowanie modułów
»Moduł jest kolekcją niezależnych komponentów takich jak klasy obiektów,
abstrakcyjne typy danych, albo bardziej luźną kolekcją procedur i funkcji;
–Testowanie podsystemów
»Ta faza obejmuje testowanie kolekcji modułów, które zintegrowano w
podsystemie;
–Testowanie systemu
»Ten proces testowania ma wykryć błędy wynikające z nieprzewidzianych
interakcji między zintegrowanymi podsystemami i problemów z interfejsami
podsystemów;
–Testowanie odbiorcze
»Jest to końcowa faza procesu testowania przed przyjęciem systemu do
użytkowania;
Inżynieria oprogramowania, wykład 1, slajd 69
Walidacja oprogramowania
Zatwierdzanie oprogramowania:
–Testowanie alfa
»Jest testowaniem odbiorczym stosowanym, kiedy system jest
tworzony dla jednego klienta;
»Proces testowania trwa do momentu osiągnięcia zgody pomiędzy
wytwórcą systemu i klientem co do tego, że dostarczony system
jest możliwą do przyjęcia implementacją wymagań;
»Testy jeszcze w środowisku wytwórcy;
–Testowanie beta
»Stosuje się, kiedy system sprzedawany jako produkt programowy;
»Testowanie polega na dostarczeniu systemu pewnej liczbie
potencjalnych klientów, którzy zgodzili się z niego korzystać;
»Klienci informują wytwórców o pojawiających się problemach;
»Testy w środowisku klienta;
Inżynieria oprogramowania, wykład 1, slajd 70
Rozwój oprogramowania
Ewolucja oprogramowania:
–Polega na modyfikowaniu istniejącego oprogramowania,
tak aby spełniało nowe wymagania;
–Takie podejście staje się standardem tworzenia
oprogramowania w wypadku małych i średnich
przedsięwzięć;
–Elastyczność systemów oprogramowania jest jedną z
głównych przyczyn, iż coraz więcej oprogramowania
włącza się do wielkich, złożonych systemów;
–Zmiany mogą być wprowadzone w każdej chwili tworzenia
lub nawet po jego zakończeniu;
–Koszt tych zmian może być bardzo wysoki, ale wciąż
będzie niższy niż odpowiednie zmiany w sprzęcie systemu;
Inżynieria oprogramowania, wykład 1, slajd 71
Podsumowanie
1. Inżynieria oprogramowania jest wiedzą empiryczną
2. Można ją uznać za zbiór dobrych, inżynierskich i praktycznie
zweryfikowanych reguł działania mających doprowadzać do
wytwarzania dobrych systemów informatycznych
3. Systemy dobre, to takie, które spełniają oczekiwania ich
użytkowników i mieszczą się w ograniczeniach czasu i budżetu
przewidzianego ich realizację
4. Wymyślono już wiele dobrych metod, modeli i narzędzi inżynierii
oprogramowania, co nie musi oznaczać, że kryzys oprogramowania
mamy już za sobą
5. Obecnie znakomita większość projektów informatycznych nie jest
realizowana w zakładanym budżecie i czasie. Jest to regularność,
która powtarza się w projektach realizowanych w dowolnym
miejscu na Ziemi.
Jak sądzisz, z czego może to wynikać?
dziękuję za uwagę